I stumbled across this quote from Mary Shaw.
Less than 10% of the code has to do with the ostensible purpose of the system; the rest deals with input-output, data validation, data structure maintenance, and other housekeeping.
I don’t know the context of her quote, but she could be talking about any software project.
When I began working as a professional programmer, I was surprised that I spent most of my time on work that wasn’t directly related to what I wanted to accomplish. Computer science classes and writing software for my own research had not prepared me for this. I kept thinking that as I got more experience, the proportion of my effort going directly toward what I wanted to accomplish would increase. It did, but very slowly, and never by very much. Only later did the reason occur to me: the vast majority of the work that needs to be done isn’t directly related to the purpose of the project.
People who know a little bit about programming can make difficult clients because they can imagine how they might write the core 10% (or maybe core 2%) of a large project.
Every once in a while someone will claim to have a solution that will change things. They’re selling a framework, a language, etc. that will radically change things. The sales pitch is “You spend most of your time doing low-level stuff. Use my product and your programmers can focus on the value-added part and not do so much plumbing.” But plumbing is value-added work. (Call it “infrastructure” if you like; that sounds more important.) Sometimes plumbing work becomes repetitive and can be reduced by reusing code, but there’s always new plumbing to work on. Most of the work to be done is invisible and I don’t foresee this changing any time soon.
Update: See this list of non-functional requirements by Mike Griffiths. This list gives some specific examples of where development effort goes, things that must be done but are not obvious until you mention them.
“I don’t know the context of her quote, but she could be talking about any
softwareproject.”Fixed that for ya. :-)
I agree completely, though. A lot of people think that I left industry for grad school because of the plumbing. I knew, though, that I was just trading for a different kind.
I agree with you on this. You are rightfully a a bit cynic about the next silver bullet, but in the last decades the abstraction at which programs are encoded and the reusability of components have increased tremendously. I also believe there is a maximum treshold of plumbing that we can code, say a maximum amount of complexity we can keep track of. So as long as we do the same amount of plumbing, but make use of more abstractions and reusable components, we still can achieve better and bigger software than we did a decade ago.
As I gain more experience I actually feel I do more housekeeping than real programming. I learn about more security flaws and keep adding security layer, be it for the input/output or the system itself.
This is just a software specific definition of the age old phrase: “The devil’s in the details.”
just guessing, maybe it can help:
functional programming in haskell
I like this. Somewhat related, I see developers trying to use Database abstraction layers, such as JDO, JPA, or Hibernate, when they could have written nice SQL and something like Spring’s JDBCtemplate. The crux of an application is usually not the SQL. Don’t get me wrong, ORM tools – and things of this nature – have their place, but some developers think they have to use them for every project.