≡ Menu
Pawel Brodzinski on Software Project Management

Custom Software Lifecycle

When we think about software lifecycle we usually fall into one of two stereotypes. We either consider application as a product which is sold in many copies (I include web businesses here) or look at software as a custom-made implementation. Probably all applications you know by their name are from the former category, but a lot of software working in core networks of banks, mobile operators etc represent the latter group.

For software products their lifecycle is fairly natural. Eric Sink wrote lately a great piece about product management of that kind of applications.

With custom projects it’s more messed. Actually most of the time when you ask someone about custom software lifecycle you hear “design, develop, implement, switch to maintenance mode, next please” kind of retort. That’s a good answer but for a different question. This is more a project lifecycle than a software lifecycle.

For custom software it goes more or less like that:

1. First version aka string and bubblegum time
You craft some software your beloved sales team has just sold. It looks like it’s once in a lifetime kind of task. There won’t be another implementation of that particular application. Most likely developers take every possible shortcut they can. No one think how scalable application is as far as it meets requirements. It can blow up when it works under 101% of planned load. The application works as it was stated in requirements but amounts of string and bubblegum used to keep it all in one piece are really impressive.

2. Fixing first version aka who the hell wrote that code?
After finishing the first version project it is switched to maintenance mode. It means you get bug reports and you have to apply fixes. If your sales team is efficient enough you also get so called change requests which are simply new features to add to the application. Now, someone has to deal with all the mess introduced in the first version. You have to work with crappy code and gradually repair major leaks. Minor ones are there to stay because no one will pay for permanent fixes in that case. It’s easier just to throw in more bubblegum. There are some custom applications which will stay at this stage till they die.

3. Next couple of implementations aka it can’t be so crappy
You achieve first success with the application. It works rather fine after a long list of bug fixes has been applied. Now if you’re lucky enough (or unlucky enough) your salespeople sale the application to another big customer. Yeah, they’ve told you there won’t be another implementation but you won’t take offend if someone wants to pay you money. Sure, the application should have a different set of features and the architecture is slightly different but who cares anyway? For all around you it’s just the same shit. Developers take a version they think is the most stable one and they start adding features and tweaking architecture. Original design doesn’t really enable customization so you create a new branch of code for that project. Later the story happens again. You end up with a few projects which are similar functionality-wise but they’re completely separate looking from developer’s perspective. Any change made in one application can’t be automatically applied in another. No matter if that’s crucial bug fix or minor tweak in UI.

4. Maintenance of multiple versions aka visiting dead-ends
You try to fix and add new features to a few applications simultaneously. Most likely you hit the ceiling with performance at least in one implementation so there’s a significant change in architecture needed. Somehow code of each project goes in its own direction. Much effort is spent to add or change specific things to one application with no value for others. Maintenance costs skyrocket. This probably isn’t an effect which senior management is very happy with. You don’t have much choice anyway so you just work your ass off trying to synchronize all threads happening in different projects.

5. Standardizing a product aka why won’t we do it as it should be done?
When sales team threatens you with another incoming implementation you make a decision which should be done at the very beginning. Let’s do it as it should be done. Let’s have architecture which supports customization to make possible changing functionality for each customer. Let’s have every feature implemented and just switch them on or off whenever needed. Let’s have one code base to fix every bug only once and be able apply all the new stuff in all implementations simultaneously. A bad news is that you’ll have to upgrade all existing crappy installations you’ve delivered so far. A hell lot work to do. Multiplied by a number of implementations you already have.

And from now on your custom software becomes much of a standard software product and you manage it more like typical application sold in many copies. It looks like primitive counting method “one, two, many” works great in that area.

in: software business, software development

1 comment… add one

Leave a Comment