Capability Maturity Models: Debating the Real Solution

http://es57025.easystreet.com/newsletter/documents/ed_carroll_0704.pdf

Alan Fisher: Ed, Thanks for the interesting article. I completely disagree, of course! Here's why: In my opinion, things like CASE, capability maturity models, UML, and various other structured design approaches are incremental solutions to a problem that requires a radically different solution. As far as I can see, programmer productivity hasn't really increased all that much since I began coding 25 years ago. But, the complexity of programs and the standards of an acceptable application surely have increased dramatically. The development problem has become so bad that many throw, "outsource it to India". The Indians can't develop any faster than Americans, or anyone else for that matter, but at least they cost less.

In my experience, only a small percentage of developers are favorably disposed to increasingly dot "i"s and cross "t"s that these solutions require. Most developers, and people in general, just aren't that detail-oriented. It didn't work with structured systems approaches in the '70's and it didn't work with CASE in the '80's. A 25% or 50% increase in programmer productivity does not interest me -- a 10-fold increase does. And that's what's required to handle the vastly more complex, broader scope applications that IT is tasked with developing today.

What is the solution? I wish I knew exactly. But I do know that various forms of so-called automatic programming and code generation are part of the solution.

Ed Carroll: Thanks for reading the article, and thanks for sending your opinion. I’m glad you wrote me back, and I hope it is ok with you if I disagree with you. I work with a team that is CMM-5 level. I have personally seen how software can be written that is bug free, where the team can flex with ever changing requirements, and still deliver what the customer needs on-time and on-budget. Would you call it an improved process if a project could be estimated with better than 91% accuracy, 95% of the time, across many projects and 800 software engineers (just engineers)? How often do the teams at your companies hit their targets?

Alan Fisher: As to achieving our development targets at Iron Speed, we work on a 3-4 month release cycle, and our 7-man team seems to always deliver about 2 weeks later than originally estimated. Two weeks out of 12-16 weeks is 12% to 17% over-budget, which is acceptable in my view since we always seem to pile on a number of extra product features while development is in-flight. (That's the nature of product development, I think.)

BUT... I'm much less worried about being 15% over-budget than I am in having the project take 4 months to begin with. I'd be much happier tolerating a one week slip on a one month project than a 4 month project, because 1.5 months is a lot less than 4.5 months. This is the real issue -- how to wholesale reduce the amount of effort required to build software.

Ed Carroll: You are right that the Indians cannot code any faster, but we Americans are also too willing to accept sloppy coding (IMO). But, as you say, the real problem is the complexity (translates into time and sloppy code) of developing products in the first place. I’ve shared this sentiment for most of my career, but what’s the answer?

Alan Fisher: I don't pretend to have a universal answer, but I do think that one solution is code generation (or application generation if you prefer) using standard components. My company, Iron Speed, is one such attempt at this solution. There are others, but the basic idea behind Iron Speed Designer, our product, is to automatically generate about 80% to 90% of a web-based transactional application (web-based database application). While we have a ways to go with our own product, we do have over 400 users who seem to be achieving substantial acceleration of custom (bespoke) applications -- what we would have called client-server applications in the early 90's.

The philosophy behind Iron Speed Designer is that a big chunk of transactional applications comes down to basic database record retrieval, data display, data input, data validation, and database record insertion. If Iron Speed Designer can automate these application functions while still providing a reasonable mechanism for customizing them, then we've achieved our goal of generating 80% of an application. Moreover, not only do you get a 4:1 reduction in amount of hand-coding required (80% of the application) you also reduce by 80% the amount of testing required since only the hand-coded portion need be tested. (Presumably the automatically generated portion is bug-free.) Furthermore, maintaining that 80% should be simpler since the tool regenerates the code each time you make a change.

Ed Carroll: I’ll keep my eye out for your progress at Iron Speed. What you’ve written makes good sense. Code generation has been tried before, but if you are limiting your application to Internet applications, than you might have a better chance at success than some of your predecessors. I believe you have a reasonable market of a lot of people who are not programmers, but who would like to be able to implement a web site of real capability without spending lots of money. Good luck.