Re: Software Development Has Stalled
Posted: Feb 5, 2010 10:01 AM
> > > In order to solve the software crisis, two things
> > be
> > > done:
> > >
> > > 1) decouple information from programs.
> > > 2) decouple programs from technical details.
> > IIRC, these were/are the design goals of UML and tools
> > which generate and manage "executable UML". I've never
> > used any of them, and since I'd have to do a bit of
> > to find them today, I doubt that any of them delivered.
> > But the effort has been made.
> This is called model-driven-design now and no, it hasn't
I'm not sure how you achieve the above. I can't picture it. It would be like decoupling the ingredients from a recipe. If you need 1 lb of beef and 1/2 cup of finely chopped onions you can't just throw in 3/4 pound of mashed peas and 12 oz of beer and expect the same results. Hell, in some cases the fineness of the chop makes a difference, never mind what happens when you swap ingredients.
Sure, the recipe isn't the food, but there is a pretty strong link there. You can only decouple so far and have it still be useful.
Maybe this is too high a level for my poor little brain. There are some technical details I can see easily being decoupled (e.g. memory management, sort algorithms assuming you don't need one highly optimized, etc.) but at some point rubber needs to hit the road.
I'm all for abstraction but at some point, like when I'm going through seven layers of managers and interfaces before I actually get to something resembling working code, my feeling is that I'm wallowing through way too much of a good thing. In my experience that sort of code has been as brittle to maintain and update as code that was tightly coupled to its data/information. I think it's a fine line.
I'm well aware that I'm a little too far on the practical just get 'er done side for a lot of people's taste, but I've been neck deep in the over-abstracted over-architected overthought projects, too. My bias in this case is that in most cases I've had an easier time refactoring and re-architecting pieces in the code that would be closer to the metal vs. code that uses a lot of abstractions and interfaces. If the code is modeled at a very high level, it makes it hard to do incremental improvements.
That's my experience. I know that others differ.