Ayende has an interesting post on the topic of selling maintainability. He asserts that:
Today's Drag and Drop's UIs, Wizards and Designers are all mainly focused on the creation side of the software. They help you with the initial bit, and leave you alone afterward. This is great for a demo, but really not a good proposition for the maintainability of an application.
His perspective is mainly of that of a .NET developer (I assume). One of the more ironic things in our profession as .NET developers is the business decision of Microsoft to pimp the long-tail of the developer tools market. Who is the long-tail of the market? The people who might be called entry-level hobbyists. This includes the guy who wants to write the quick and dirty application to track his little league baseball team's roster and stats. For John Hobbyist, the dragging and dropping of components with very little "glue" code meets his need quite nicely. He doesn't want the messy long-term commitment of design and quality. He wants a quick and dirty application--right now.
How does Microsoft achieve this? They accomplish this by pimping Rapid Application Development (RAD) and packaged, off the shelf components. They give us WinForms and WebForms frameworks and a set of components with which to quickly "assemble" applications. These off-the-shelf components are both visual (Datagrids, TextBoxes, etc) and non-visual (DataSets, Timers, etc). In many instances they even wire the components together for us (ie..change tracking propagated to the dataset from a datagrid).
This basic environment works really well for the guy building the app for his little league team or the power business user creating a new utility for his peers to use. The problems occur when you get off the beaten track of the environment. This includes doing new and unexpected things with the existing components. The intimacy required of application complexity kills any quick and dirty advantages previously seen.
As an example, drag a table to the form, do the designer magic, and then try to add business rules about who can see what and how to the page. Is this a maintainable approach?
My answer is a resounding no!
Was the intended use of the components to create maintainable applications? No. They were created for Rapid Application Development. This works when the coding is mostly little bits of glue assembling the components (such as the little league app). One might argue that RAD also works well for consultants who get paid to deliver a fixed amount of funcationality on a greenfield project, and then hand the beast off to corporate maintenance programmers. This works well for them because the RAD approach yeilds the solution in the shortest amount of time (giving the greatest profit) while leaving the pain of maintenence to be felt by someone else. It can backfire on them though after lots of little scope changes.
This same RAD component paradigm also works really well for Microsoft. One of the benefits of shipping components is that components can be developed in a distributed fashion. You can ship each component off to an individual development team to create and test. This yields a very quick time to market for sets of new components.
In the context of selling maintainability, I might argue that instead of trying to sell maintainability to project stakeholders, just expose the true programming model the the wizards target. Those wizards were never meant to be used in applications which have to be maintained as long-term commitments. They work best when applications are small, and when new releases can be rewrites (ie..rewrites of the glue code). If your boss is ok with the costs and timelines associated with rewrites as well as the limitations of the current set of components, the wizards are a viable approach. Just make sure to include the lengthy debugging phase in your development timelines.
Now, we could call Microsoft stupid for this, but I would argue just the opposite. As much as I dislike the decision to drive in this direction, I think Microsoft probably made a smart business decision for them and their shareholders. They will probably gain more market share, and sell more copies of their development tools as a result. Unfortunatly, this causes many of the professional users pain. We want to sell maintainability. They want to sell developer tools. It's a conflict of interest. They sell by promoting ease of use and rapid application development. We know that what comes quick and easy is not usually high quality.
As a result, we could throw out the baby with the dirty bathwater, but I think there is much value left in the Microsoft platform even after removing the wizards and other unusable developer eye candy. The .NET framework is really an off-the-shelf runtime middleware platform for components. It was an evolutionary extension of their earlier COM/COM+ component runtimes. This is why we have things like reflection, versioning, code-access security, language independence, support for explicit separation of interface and implementation, JIT, and the other hallmarks of component-orientation. You can compare .NET to many other runtime platforms, such as CORBA, J2EE, and a host of other technologies. It's also nice when your entire stack (including IDE, OS, Runtime, and RDBMS) all come from the same vendor. They come ready to take full advantage of each products features/strengths.
In short, you need to ensure that your project stakeholder understands that the off-the-shelf RAD paradigm does not produce maintainable applications. It's meant to assemble quick prototypes of existing functionality (off the shelf components). If he wants functionality that's not off-the-shelf, he is treading into dangerous water. Now, to Microsoft's credit, they did give us quite a bit of extensibility points into the off-the-shelf components (think Databinding in a DataGrid), but real problems exist when the "glue code" between components becomes larger than the components themselves. You are then left with a developer whose architecture and design (the clumsy structure around the components) is basically non-existant. From here we could plow directly into the topics of techinical debt and lots of other pain points of application development.
Ironically, this isn't just a Microsoft problem, but rather a problem of applying something in a context to which it does not work well. It's the exact same problem some people run into with code generation and a host of other techiques and tools. Know your development paradigms. This includes knowing both the strengths and weaknesses of each. If your project stakeholder thinks that off-the-shelf RAD components are the one true way of building applications, kindly remind them that there is no silver bullet. You shouldn't use the RAD approach for long-lived development projects just as you shouldn't build a domain model for a very very simple application (ie..done in a day and a half).
As an irony of ironies, RAD was developed as a response to the shortcomings of waterfall. You might call it the great grandaddy of interative software development from the late 1980's. Given the history and shortcomings of off-the-shelf RAD development, selling your project stakeholder on other, more modern agile methodologies should be quite a bit easier--especially when you can explain why Microsoft works this way, and why it's less than ideal for the application you are about to create.
In my experience, complexity and maintainence are the killers of off-the-shelf RAD. Most of the applications I have worked on in a professional context have involved both. Where you go when off-the-shelf RAD isn't appropriate will largely depend on developer skillsets, knowledge, and preferences. Someone from the component world might argue that you should create additional components. My personal preference for building complex, maintainable applications is to use a combination of object-orientation, domain driven design, and test-driven development. Of course, getting all of that within a single project or employer is something I have not had the pleasure of accomplishing yet.
Finally, don't dismiss RAD as worthless either. While the complexity of the application's solution domain (the domain model space) might rule out RAD development with off-the-shelf components, the presentation layer often does not. For business applications, building the GUI out of off-the-shelf components (ie.. TextBoxes, Dropdowns, etc) actually works quite well. You couldn't use them to create an application with a very complex user interface (say, a new computer game), but then we see that computer gaming companies have the same beef with off-the-shelf GUI components that we business application developers have with off-the-shelf application components.