RAD: The Reason the Domino Development Platform Isn't Taken Seriously?
Bookmark :
There are a few people talking about things that are really important to me:
Tim Tripcony "Domino Developers Are an Afterthought"
Sanity Check
I've commented on those blogs directly, but I felt I needed to put all my thoughts into one place.
All these threads have 2 basic themes in running throughout the comments: Has IBM ignored the Domino development community? and, Is it time for the Domino developers out there to grow up?
Both of these are coming out of the same conversation because I think we are at a point where, in order to improve, we, as Domino developers have to grow up. To put it simply, we need to examine our practices using Rapid Application Development (RAD). (more)
Domino Designer is going to follow the client and move to Eclipse. This, in itself, is a huge change. Eclipse is a much bigger, more robust development environment than a lot Domino developers are used to. This, understandably, makes a lot of people nervous, but it has to happen. As strong as Domino is, proprietary environments cannot attract as many customers as open ones can. Things can't stay the same forever. This, though, doesn't mean IBM has stopped ignoring the Domino developers. Change for the sake of change isn't the answer. IBM has to deliver solutions in the form of a powerful IDE that solves the problems people are having today, and not just solving problems we don't have yet. IBM has to recognize that the problem isn't just that Domino developers don't have enough Java in their lives, but are having real problems with the stuff they have now. In a lot of ways, Designer today is OK. Sure there are plenty of ways to improve it, but a lot of the real issues are with the features that Designer is allowing you to utilize. Embedded Views, for example, are just not useful the way they are currently implemented. If this doesn't get fixed, it doesn't matter that Designer is based on Eclipse.
The other theme that came out of this, and I'm going to generalize to make a point here, is that Domino developers need to grow up and get serious. I am 100% convinced that the reason that Domino as a development platform isn't taken seriously is almost completely the fault of the people doing it. Here is where my criticism of RAD comes back. RAD is a property of the tools you use that helps you develop applications quickly. It is very quick to create some forms and views that deliver a business function that would probably take a lot longer in Java. Just setting up the UI alone is massively time consuming in more traditional environments. That is where RAD should stop. RAD does not mean you don't have to DOCUMENT any of that great stuff you just created. RAD does not mean you don't have to TEST all that great stuff you just created. RAD is not an excuse to bypass all the good practices that other environments use. It's not that Java developers test or comment their code because they don't have a RAD tool, they do it because that is what is required of software development projects. The mail template that comes with Domino is a Notes application. Designer is used to create it. Does that mean that IBM doesn't have to do anything beyond code it up? Of course not, and everyone would be up in arms if IBM just waited for the Users of Notes to report back to them that the send button didn't work, or the selection formulas in the views were wrong.
The world is changing. It doesn't matter if you are a small one man development shop, or a huge IT department in a Fortune 10 company. If Domino development is ever going to be taken seriously and move out of the 'toy' stage as John said, it has to start with the people most closely involved with its use in real life. If that doesn't happen, than it doesn't matter what IBM does with Designer. Domino development could be done pure Java and it would still be considered a toy not fit for the 'real' apps and that would be unfortunate.
The other theme that came out of this, and I'm going to generalize to make a point here, is that Domino developers need to grow up and get serious. I am 100% convinced that the reason that Domino as a development platform isn't taken seriously is almost completely the fault of the people doing it. Here is where my criticism of RAD comes back. RAD is a property of the tools you use that helps you develop applications quickly. It is very quick to create some forms and views that deliver a business function that would probably take a lot longer in Java. Just setting up the UI alone is massively time consuming in more traditional environments. That is where RAD should stop. RAD does not mean you don't have to DOCUMENT any of that great stuff you just created. RAD does not mean you don't have to TEST all that great stuff you just created. RAD is not an excuse to bypass all the good practices that other environments use. It's not that Java developers test or comment their code because they don't have a RAD tool, they do it because that is what is required of software development projects. The mail template that comes with Domino is a Notes application. Designer is used to create it. Does that mean that IBM doesn't have to do anything beyond code it up? Of course not, and everyone would be up in arms if IBM just waited for the Users of Notes to report back to them that the send button didn't work, or the selection formulas in the views were wrong.
The world is changing. It doesn't matter if you are a small one man development shop, or a huge IT department in a Fortune 10 company. If Domino development is ever going to be taken seriously and move out of the 'toy' stage as John said, it has to start with the people most closely involved with its use in real life. If that doesn't happen, than it doesn't matter what IBM does with Designer. Domino development could be done pure Java and it would still be considered a toy not fit for the 'real' apps and that would be unfortunate.
Comments
That is different, to me, than the discussion of whether a particular IDE or language should be used in a particular way. It is a larger issue, involving department managers just as much as developers.
And I also agree the moving Domino Designer to Eclipse isn't a panacea. It will help in some areas, but it's irrelevant to others (embedded views being one, and a similar issue with Composite Apps being another).
I do think there's more room for significant tooling improvements, though. The lack of a testing framework for Notes applications makes our QA efforts much more difficult (and more error-prone) than similar efforts in our other development groups. We can automate some web testing for our Domino apps, but automating the testing of Notes apps isn't feasible. Maybe a new product idea for you guys? *hint, hint*
Posted by Rob McDonagh At 12:32:42 PM On 12/04/2007 | - Website - |
Posted by Pablo Barlow At 01:57:26 PM On 12/04/2007 | - Website - |
My original point was that there are a broad range of reasons why I feel like IBM occasionally forgets we're here; the lack of any significant changes to Designer since '99 is just a drop in that bucket. But I'm glad that it triggered this secondary discussion... for Notes/Domino to be successful, IBM has to keep their focus on the end users, but so do we. If we're not evolving our processes to leverage both the strengths of the platform and our own strengths as developers, the end users lose out, no matter how happy we are with our IDE and associated plugins. They have to wait longer for feature delivery, settle for buggy / sub-optimal performance, and cope with interface inconsistencies, both within individual applications and across the infrastructure as a whole. After all, the users are the whole point. So the more powerful - and yes, the more rapid - we are, both as a result of the tools available to us and the processes we follow, the better off the users will be... and, generally speaking, the happier we will be.
Posted by Tim Tripcony At 04:25:17 PM On 12/04/2007 | - Website - |
They aren't? I guess my users don't know useful when they see it.
The rest of your essay, I'm with you.
Posted by Timothy Briley At 05:22:06 PM On 12/04/2007 | - Website - |
So.... Embedded views referencing other databases are a problem because you cannot change the database they come from easily. If you cannot guarantee what the repid is once the database moves off your dev server, you cannot really use them. As a result, you will probably end up working in production, or at the very least referencing 'live' data. And this is where everything falls apart.
Posted by Craig Schumann At 05:41:27 PM On 12/04/2007 | - Website - |
Accidentally, I did a presentation about design patterns at the Lotus Developer2007 Europe today. I blogged my thoughts about the "feeled result" and my considarations:
{ Link }
And I asked the question: Do LotusScript developers use object-oriented programming in their applications at all? And if not, why not? (Please comment on my blog)
I really believe, it's not only sensible, but necessary to use OOP for large applications. And having a time-proven framework based on sound OO design principles in place helps for the "rapid" in RAD while keeping the code highly maintainable and flexible and easy to understand.
Posted by Thomas Bahn At 07:59:02 PM On 12/04/2007 | - Website - |
I have to agree that more powerful tools won't solve people problems. If there's one thing I've learned from writing Notes apps all these years is that you can't solve people problems with software. But good tools help. In fact, I was CIAO'n like a fool today
Posted by Dan Sickles At 10:12:48 PM On 12/04/2007 | - Website - |
Posted by Henning Heinz At 05:41:33 AM On 12/05/2007 | - Website - |
Enhance Designer to include comments and to-do lists on the actual design elements in the NSF template.
Build in work flow for specific development situations.
Actually change Designer so that a developer can create a form/view/page, attach it to a design element and extend designer directly.
Build hooks into the compile/save/open events and allow the developer to respond to those events with his own code - or - third party code.
Posted by Wayne Sobers At 07:59:11 AM On 12/05/2007 | - Website - |
Clients many times get an ugly application and say, "Well that's Domino (just plain ugly)" and get discouraged.
I would encourage Domino developers to read books like 'Code Complete' and study UI discussions such as those being done by companies like adaptive path and 37 signals.
Granted Domino has limitations in it's OO interface and the web interface but it's still a great underlying platform for high end development (in the right hands).
Posted by Jim Knight At 09:04:21 AM On 12/05/2007 | - Website - |
I blame the lack of real source control and version control (TeamStudio just doesn't cut it) for corporate adoption.
I blame the developers who fear creating function and sub routines. They're still using GoSubs
I blame IBM's implementation of Java in Domino for the reason we still develop in Lotusscript. (Common saying at a Domino/Java shop: "Is our web server getting slower? Who didn't recylce their document object? Nooooo!!!!")
I've seen the Eclipse/R8 demos. I have hope. Grab your "Head First" series of books and let's get coding!
Posted by Tom At 12:31:14 PM On 12/05/2007 | - Website - |
It seems every company today is establishing process controls and are frustrated because they cant get Notes to fit. The managers take one of 3 tacts. 1) they try to apply process controls meant for j2ee or .net anywise and Notes development suddenly becomes as expensive and slow. 2) They've given up and just let Notes grow wild and neglected. 3) Their planning to rid themselves from the problem child and will migrate as soon as they can convince the budget committee
Is it the managers fault? They are trying to meet compliance requirements from above, .net and java have text book examples. Can they trust the "crazy notes developers" who live in the basement, shun Microsoft, and seem to always do things different. In vain they go to the web looking for best practices and only find more questions, and articles proclaiming "notes is dead."
It managers don't want to invent a process from scratch, they want to copy one from a text book, tweak a few points, deploy, and collect their bonus. Currently Notes doesn't fit the text book examples, and without IBM providing text book processes these managers are fed up with the "different" child. They are also fed up with Notes developers who seem like problem children too as they just wont behave like the .net kids.
I really have to put the onus on IBM to give more legitimacy to Lotus Notes Development processes. They need to create, document, and promote best practice methods. They need to show by example how managers can develop with Notes, meet controls, and still keep development cheap and quick.
Posted by Brian Vincent At 07:19:52 PM On 12/07/2007 | - Website - |
@11 - Tom, .... ok.... I have to ask.... Why isn't Teamstudio ready for the enterprise?
@12 - Brian, Right on! I think you have tuned right in to my frustrations. I may not have id'ed the same culprit as you but, we both are feeling the same thing.
Posted by Craig Schumann At 08:20:48 AM On 12/08/2007 | - Website - |
The people who have the "power" to push application platforms within a corporation want to:
Posted by tom At 01:55:16 PM On 12/09/2007 | - Website - |
The people who have the "power" to push application platforms (Java, .NET, Notes) within a corporation want to:
- Understand the platform
- Control the code (using THEIR tools)
- Audit the changes (also using THEIR tools)
It's not TeamStudio's fault Enterprise tools can't be used... it's a "fault" of the platform (no text files).
Until the people in "power" can do the three things above with Lotus Notes... we're stuck being the red-headed step-developers in a corporation.
Posted by tom At 02:01:59 PM On 12/09/2007 | - Website - |
Seriously...I've been in businesses that use notes and expect admin assistants to create notes applications. Once any real complexity comes up in the scope.... notes will suffer....IBM ... make notes more complex...oh wait... that's what you are doing :)
Posted by Mr. Anonymous At 02:35:19 PM On 12/14/2007 | - Website - |