+972 52-548-6969
How to sell maintainability?
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.
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!
But it does make for a very compelling demo. The maintainable approach, on the other hand, takes more time, and involves more moving parts that a drag & drop operation. Comparing the two is a problem, because one looks so much easier than the other, and in the confines of the typical demo (or indeed, the quick prototype), those problems are not usually seen.
So, the question is, of course, how do you sell maintainability?
Comments
The ease of which such "impressive" demos are created has often resulted in creating a false sense of simplicity to the "business" people.
I've seen plenty of cases whereby these business people think that the demos (or POCs) were already 50% done and expected the whole project to be completed in a couple of weeks. Without some one to guide and advice them (if they are willing to listen in the first case), these projects often fail and exceeds timeline / budget.
And they will blame the technical people for it.
Who does this problem apply to? Contractors? They deliver solutions, not tools. Software shops? They will quickly figure out wizards are not the way to go. Software shops creating software for devs? They do pick their target audience.
I personally don't have problems with wizards, only with the code they generate ;-)
Why can't we have both?
It should, in theory, be possible to generate a graphical designer that writes nice POCOs, generates the appropriate XML config files for your DI/Persistence/etc tool of choice, etc.
Even higher level designers for writing your tests first in TDD should be possible? Perhaps something that guides you through the process of stated business requirement (i.e. the total of debits in the general ledger must equal the total of credits) - to tests that test for that (Assert(account.debitSum == account.creditSum); While this sounds somewhat silly - in practice, would only be used to demonstrate the TDD process to someone you were selling it to. Most people don't visualize in code - anything we can do to help them visualize the process in a tangible way can help.
In other words, I question the premise that designers and maintainability are mutually exclusive. I DO agree that we need something that demonstrates to the business why development that goes between "proof-of-concept" and working code takes much longer.
An experienced customer (i.e. once who has gone through plenty of wanna be programmers) knows the difference between a programmer who tells him plug-and-play works, and one who explains why plug-and-play is for the demo only.
If you are stuck with a boss who ignores this advice, just politely position yourself for the moment he goes up in smoke, then politely ask if you can use plug-and-play only when it's appropriate.
If your boss still ignores your advice, get a new job or suffer with a fool.
We have to figure out how to code maintainable solutions at the same pace as we code demos and prototypes. I personally think that .NET will have to undergo some possibly significan't changes before that can happen.
Scott,
I really don't think that this is possible.
Throwing a grid on a form is very easy, but writing a maintainable security solution for the data that is shown in the grid is going to take time, no matter what.
Just understanding / implementing the business concerns that goes into real piece of software is going to take time,
I blame the MS propaganda machine that hold these events that CIO's and Product Managers attend showing how simple it is for developers to create complex web site or smart apps with a few click and a database. Please!!! That expectation is set.
About the only way I have been able to sell maintainability is through quality. I know this is by no way a correlation but they ( non technical stakeholders) understand quality. I simply remind them of PMBOK models about introducing quality early on in the process has a higher rate of quality as the project completes.
I have been experimenting with using Technical Debt models. Since I am in the finiancila sector, debt is something everyone understands as bad! With every release I have been trying to document the amount of story points we have delivered vs. the amount of techinical debt we have incured.
One funny story is that several releases ago there was a feature that we developed. The problem was the business was wrong about how the feature should function but we discovered it 2 days before the release date. We scrambled and applied TDD but we knew we were compromising the architecture, I informed the business that they are incurring a huge deficit by still holding this date over our head. In the end the date one over the application architecture. I took several rudimentary graphs that I had constructed and started sharing them with my executive managements to value vs debt. The funny part was when the product owner approached me several months later and asked what she could do to get out of this technical debt.
I've left my reaction on my blog (not sure why the trackback didn't work).
Off-the-Shelf RAD is for Pimps, Hookers, and Johns--Not Marriage
http://www.evanhoff.com/archive/2007/09/09/51.aspx
"I've seen plenty of cases whereby these business people think that the demos (or POCs) were already 50% done and expected the whole project to be completed in a couple of weeks. "
We should extract revenge! Let's write an application that does manager desicions, contract negotiations and sales. It will, of course, be laughable but it will support drag n drop in a demo. Then we'll all pretend to be mesmerized by this app and turn to the business people, saying "Guess those contracts will be done by Monday, then."
/Mats
Comment preview