What is software "maintenance" anyways?

Something that has been beginning to annoy me lately is the term "software maintenance".  Why?  Because the metaphor of maintenance is meaningless to a technical person and implies too much meaning, that doesn't fit software, to business people.  What are these oh-so-bad implications?  Ever hear any of these?

- "Maintenance projects can't use, or are not a good fit for Agile."

- "[Jane/Joe Programmer] is a maintenance developer."

- "80% of a (software) project's costs are from maintenance."

- "Maintenance funding is a corporate expense." (vs. a capital investment)

- "[Project X] is in its maintenance phase."

Some of these sound important, like project funding or costs, and others sounds absolutely ridiculous.

First, let me define maintenance using my favorite definition:

"The work needed to keep an asset in a condition that enables it to retain its original value or service potential.  Maintenance does not extend an asset's normal expected life." -- [Here is the original source I tweaked it to be a bit more specific.]

Next, let's take a look at the kind of tasks one might see on a so-called maintenance project.

1. Bug fixes

2. Performance tuning

3. Infrastructure/Technology upgrades

4. Refactoring (improving code without changing its function)

5. Enhancements and changes

6. Adding whole new features

After reviewing the list above, a few things jump out at me:

First, only items 1-3 fit squarely into the definition of maintenance given above.

Second, for every maintenance project I've ever been on, 60%-80% of my time was spent on items 4-6.

(So why do we say that 80% of a project's costs are in maintenance when so much "maintenance" activity is not even really maintaining the product?!)

Third, (and most importantly) all the items on the list are things I do on new development projects!

My conclusion?

It's all just software development!  I know this isn't exactly a great revelation to techies or anything, but it is important that this is realized, especially by managers and business folks.  "It's all just software development" is the technical equivalent to "he's just not that into you".  This realization frees the mind from the flawed metaphor of maintenance and all the wrong preconceived notions it drags along with it.  Of course Agile principles sill apply; its software development! So-and-so is not a maintenance developer.  So-and-so is just a developer!  Software doesn't have a maintenance phase that is costly.  There is simply a choice of whether to continue to add value to the business by enhancing the software or not.

A few caveats before I get flamed.

Yes, continually enhancing code can become very costly if corners are cut, test harnesses are not in place, and technical debt continues to pile up.  Usually at some point, a critical mass is hit and, if the system is needing to be enhanced, a rewrite will be required.  This brings on problems of its own that could (and maybe someday will) warrant its own blog post.

Yes, there is such a thing as maintenance for software, but I will assert that it is only items 1-3 in the list above.  Those are the only items that simply maintain the software in its original intended state, providing its original intended value to the business.

So what is missing?  If its "all just software", why do I like some projects and not others?  What is the key differentiator?

Well, some projects I don't like because I inherited them and they were poorly designed or poorly written or dont have any tests, or seems like some amorphous blob attempting to suck out my soul.  But you know what though, while these can be sluggish to wade through, there is also some sense of accomplishment in getting to make it all better!  It is a different kind of joy than getting to design and implement a brand-spankin-new solution, but both are programming and both can be enjoyed for different reasons. So I dont really believe any of those negative aspects of Legacy Code are the key differentiator.

I think the real issue is something I have started calling the Development/Support Dichotomy, or DSD for short.  DSD occurs when some piece of a software project is being used in production.  The problem this causes is when something breaks hard and business stops or is severely impacted and the team or individual working on the project must stop planned work and react to unplanned work.

My next article will be more detail on DSD as well as ways to solve it.  For now, can we all agree that true software maintenance is pretty narrowly defined, and not actually that bad?  Could we further agree that, most of the time, what we are asked to do under the term "maintenance" is actually some other kind of on going software operations? (or even better, continued investment?)  Great!  Now let's get the business and management types thinking and speaking that way!

On Corporate IT Innovation

So the place where I work is going through some sort of "innovation phase".  That's not quite the right term, but I dont know exactly what the right term would be.  I'll try to explain.

So we've recently been hearing from our CIO about innovation.  Apparently we are wanting to do this.  What confuses me though is that I'm not even really sure what this means.  

What I do know is that we get "innovation emails" from the CIO.  These emails are all examples of innovation that have happened somewhere else, and often not even in IT.  The last one I actually read had to do with the guy that came up with the idea of "kids stay free" at hotels?!?

So you can imagine that these emails soon became the butt of many jokes around the proverbial water cooler, and more often than not wind up getting deleted unread (if you're reading this big guy, sorry, but that's the truth).  

More over, all the emails (that I've read) were all what I would call Grand Slams.  They are the kind of things that massively change something big; a business, an industry, a paradigm, our lives.  

Are these the things we are being asked to produce?  Probably not, but then what is the message being sent by these emails?  I couldn't really tell you...though I guess it doesnt really matter as not too many people read them anyways...but what a waste; all those electrons :(

In my opinion, the outcomes of those emails are not what should be studied or sought after, but the environment that allowed them to happen.  Sure it's possible that occasionally someone just gets a really bright idea that revolutionizes something.  It's also theoretically possible that an infinite number of monkeys with an infinite number of typewriters will eventually write a Shakespearean play.

More often than not an environment that fostered and encouraged innovation is what allowed the innovation to happen.  What type of environment is that?  Glad you asked :)

- An environment free of blame and fear, and full of trust

- An environment that allows for creativity

- An environment where continuous small improvements are appreciated

- An environment that encourages people to learn, reflect, and grow

- An environment that values diversity of thought

- An environment that embraces emergence and evolution

- An environment where change is considered an opportunity, not a threat

- An environment (for software development) where more is measured than just delivery

I could probably go on, and before you know it we would all be singing koom-by-ya around a campfire and giving each other back rubs...why?  Because all those things are that squishy leadership/management/organizational behavior stuff that is hard to measure and impossible to mandate, yet necessary for individuals to flourish.

Most importantly these things take time.  Some executive cant just decide "We havent innovated in a while boys!  Lets do that now!"  It takes someone with vision and faith, and I don't mean religious faith, but the same principle applies.  Belief in something that is hard (or impossible) to measure, but you just know is the right thing to do.

I'm not saying that everyone should just do what ever makes them feel good.  I mean heck!  There is a business to run right?!  But it is possible to put mechanisms in place that revolve around certain ideals that, over time, build the kind of environment that allows for innovation.

So stop trying to innovate or be innovative (and please dont create an "innovation award"...yes we have that too >_>) and take a good look around and ask yourself what small thing can I do today that would help build an environment where people will be able to innovate tomorrow.

It Has Begun...

Hi, I'm Matt Barcomb and for better or worse I've decided to add my $0.02 to the blogosphere.

I plan to use this blog to talk about issues revolving around software development that interest me.  Currently such topics are (in no particular order):

• little-'a' agile
• alignment between software development and business
• software testing & design
• leadership & communication
• non-technical organizations with internal software departments
• software craftsmanship
• education/training of software practitioners
• culture building and transmission
• some occasional random rant, most likely vague and ideological

Some background (semi stream-o'-consciousness)...
I'm married to a Brit who lovingly introduced me to stinky cheese, mouthy red wine, fresh vegetables, travel outside the U.S. and <mushy>has given me more that she will ever know.</mushy>  I've also got some pets: 2 dogs, 2 cats, and 1 son ;)  We pretty much always have a blast, so thats< really cool.

I was introduced to programming in 3rd grade (Apple basic ftw!) and started programming on my own in 5th grade (GW Basic ftw!) and have just sorta always been doing it ever since.  However, I've been a *professional* software developer for just over 11 years now. Spent about 6 years at a couple of small, boutique consulting companies in Kansas and for the past 5 years I've been here in Omaha doing programming for the railroad...oh, and I also have been teaching some IT and business classes in the evenings at a local college since i've been in omaha.

I've recently (months) changed paths from programmer to manager. Why?  Heh, sometimes I wonder myself, but generally because the bigger, fuzzier, and more variable the problem the more I like it.  Also, because the way I'm wired is to get involved where I see a problem I want to change and software management at my non-tech transportation company was where I saw the bigger, fuzzier, more variable problem :)  Plus, I can always program on the side on my own time...kinda hard to do that the other way around :P Who knows...we'll see where this takes me for now.  If I don't like it I can always become a guitar playing scuba instructor back in Florida!

As for hobbies, just about anything interests me initially enough to read and investigate and conversate.  Oddly, given my tech background, I'm also strangely intrigued by agricultural things...probably something about the growing/building/creational aspect or something.  I like almost anything outdoorsy especially involving water, but recently activities haves been mostly walks and camping (and there isnt a lot of water around Omaha that is worth being around). However, I'm thinking about getting back into scuba diving (yes, in Nebraska, and *no* I dont think it sounds silly) and have been thinking about getting sailing lessons.  There is also this acoustic guitar in my basement that taunts me to learn how to play it >_<

What else...well, I'm from Florida, but currently live in Omaha...yeah...don't ask...I'm not overly happy about it, but it is what it is for now :P I was in the military for a few years (FA w00t!).  I went to K-State where I did comp-sci and MIS. I eventually got my masters in project management with a concentration in operations research.  No I didn't get my PMP 'cause I dont think the PMP is worth the time, effort, or money when applied to the software industry, though that may be changing with PMI-Agile...we'll see...I can always get one later.

As for my blogging, as you may have seen, I'm not overly fond of capitalization, and the apostrophe and I are on shaky terms as well.  I do hope someone gets something out of this besides me, but me is mostly who I'm doing this for...dang it...i mean; me is for whom I am doing this (yeah, that just sounds weird) so I'm likely not following the right blogging rules or whatever, but if you've made it all the way down here, I hope you were as entertained reading this as I was writing it :D