Identifying The End of the SDLC (2015)

Killer QueenDeath is not the opposite of life, but a part of it.Haruki Murakami

Software projects die. Call it retirement, ‘end’, whatever you wish – they die. In a perfect world, this is planned for – expected – understood. In the real world, many software projects were never established formally and have to be brought, kicking and screaming, to the table for hard decisions to be made.

Some software projects continue living out of some perverse masochistic need to keep them living – but they’re dead but for the efforts of those keeping them alive. Sometimes it’s necessary to admit that the software is beyond repair if only for a business to stop losing money and by that time a company is already deep in the quagmire in the project.

This, of course, is written mainly for businesses with software projects. Some are defined as software projects and some are not – I’ve encountered quite a few software projects over the decades that started off with the question, “Wouldn’t it be nice, if?”, and evolved based on that – a spiral model of requirements that doesn’t necessarily translate into a spiral model of development. While I have worked on successful projects and the world celebrates such successes, it’s the failures that create best practices and other rules of things-not-to-do.

A best practice should be planning for the end of the software life cycle throughout the life of a project – including planning the project. That’s part of any solid software development plan – a living document of a project. that exists in one form of another, be it in one person’s head or many people’s head. The latter creates the conflicts in a project that putting the document in written form so necessary. If this development plan doesn’t exist, identifying the end of the software project – it’s death – is almost impossible.

There are a lot of my fellow professionals out there who know about the software development life cycle to varying degrees of intimacy. In theory, we all want to begin things properly but we never discuss the end too much – and, oddly, the end is typically what employs the most software developers outside of relatively few software companies – the fact that when the software project was started no one planned for planning for it’s death. “Just one more change”, someone will say in consternation, “and we’ll move on to the next evolution because…. <insert your phrase of choice here>“.

It’s rarely blatant to management, and depending on what motivates the software developers, they may be immune to the pungent smell of necrosis if only for fear of not finding employment in a job market that is less than friendly.

For any technology to be sustainable, the economy surrounding it must be sustainable. Identifying the end of a software project requires attention to new technology adaptation both inside and outside of the user demographic as well as an actual interest in what the user demographic wants (will pay for) and needs (what it cannot do without).

The key to knowing when a project is dead is assessing whether the project will make more money than is being spent on it. I’ve worked on projects decades old that were still quite profitable and I’ve worked on projects a year old that were money pits – and a business that keeps throwing money into the money pit is unlikely to remain in business longer than their capital permits.

So how can you tell whether a software project is necrotic? There are a lot of very subjective things that have to be considered, such as the business direction and vision of the future as glimpsed by management – and they color the items listed below as well. In the end, it’s up to management.

There are also very, very simple things that will tell you whether it’s time to break out the candles for the project and will help assess whether any software project is in it’s death throes – or toxicly necrotic for the business.

  • Spending More On The Project Than It Brings In: While this is true of most startup software, the subjective aspects of vision and business direction overshadow it – and sometimes they continue to do so longer than they should. A software project should have a budget. Your company can fight over what is considered an expense and what is considered revenue (it’s not always cut and dry), but if you’re paying software developers more than the project is bringing in, someone should begin asking questions. Startups might be considered exempt but they shouldn’t be – at every iteration, this has to be looked at and with startups even more so than mature projects. Why? A misstep could be the end of it all.
  • Underlying Technologies Are No Longer Competitive/Supported: If you’re required to run a project under DOS or CPM, it may be time to pull the plug. If there’s a niche market, that’s nice. Just make sure that the niche market is paying your overhead and profit. Another example might be a lot of code that is not compliant with the latest and greatest strides in the language. I’ve seen PHP 4 code stuck on LAMP servers that belong in museums – running live on the Internet, where script kiddies are more than happy to show the willing that it’s time to move on with their probing.
  • The User Demographic Says So: Users are a peculiar group of people who don’t necessarily write long and detailed emails about what you’re doing wrong for them – in a world full of software options, it’s hubris to think that your company is so special that your users should invest themselves in your product. Social media makes getting feedback easier but tweets like, “your product sucks” just don’t give the granularity necessary to steer the project.

There are no silver bullets in here. Everything has to be considered within the context of the business and the key problem is that there’s a level of introspection required that wouldn’t have allowed the software project to get where it is now. It can be an uphill battle with those who make decisions since they may have seen how much they invested in the technology in the past as some form of wedding ring.

Image at top courtesy Louise Docker, who made the image available under this Creative Commons License.

Getting Out of Firefighting Mode (2015)

WildfireIf Prometheus was worthy of the wrath of Heaven for kindling the first fire upon earth, how ought all the Gods honor the men who make it their professional business to put it out? – John Godrey Saxe

Sooner or later any seasoned software developer, programmer or project manager finds themselves in firefighting mode – where it’s a matter of putting out a fire so that it doesn’t spread to other things, taking a project down. Some people think that the ‘fingers in the dyke’ are a more appropriate metaphore – and at times that is true – but I’m writing about firefighting today.

Getting out of firefighting mode is relatively easy. Like fire, there are certain things that are needed to create the conditions for the fire in the first place. A fire needs fuel, oxygen and a source of ignition.

Oxygen is easy in a software project – it’s a requirement for the software project to start and survive in the first place: users.

The fuel, all too often, results from poor software and system administration practices and poor management decisions.

Like fire, the ignition sources can be many. It can be the fuel rubbing together to form the friction (bad decisions culminating into a burst of flame), or a visiting pyromaniac (someone taking advantage of an exploit), or enough oxygen (users) blowing over a hot spot (friction) that causes a burst of flame.

The only way to get out of firefighting mode with a software project is to deal with the cause of the fires. Sure, putting out the fires is important, but sometimes you can’t put them out fast enough – and unless you treat the underlying cause, the fire will gut the project.

Almost all the time, the people who have been fighting the fires have opinions on what is causing all the fires – and they typically have a plan to tackle them, if only they had time or management approval. Despite our best efforts in Hollywood, time travel is not yet viable – and that leaves us with management decisions. Management decisions over a period of time become company culture. A culture that is derisive of good software project management is almost impossible to change unless something drastic happens.

About 15 years ago, I came up with a phrase that seems to be pretty accurate since: Management doesn’t smell the fire until the flames are licking their posteriors. Until they understand that there is a problem that needs to be solved, they will not try to solve it. The time can vary depending on how much attention they are giving to the issues and, where the real problem usually is, how much they trust the people that they hired to talk to warn them about these things.

If you can’t solve the management/leadership problem, you’re sunk. You’re done. Cash in your paychecks and update your resume.

If you can get management to see the need for change – probably with the help of someone in finance who will point out how much money is being spent fighting fires – the only tried and true way to get out of firefighting mode is:

(1) Take a hard look at whether the project is dead or not. If you’re so bogged down in maintenance mode, it’s time to figure out what Plan B is. If not…

(2) Start implementing best practices, from source control to documentation of the project itself. When there are too many things going on, find a finite area to begin controlling and start controlling it. It’s an uphill battle but it can be done with management making the path clear.

(3) Draw lines in the sand. If fires don’t meet certain criteria you set – don’t fix them. This is triage and has to be decided with the overall project in mind.

Image at top courtesy U.S. Fish and Wildlife Service, Southeast Region, and made available under this Creative Commons License.