Paraphrasing Uncle Bob’s “Clean Code” and his Code Smells that are so famous and popular nowadays, like the ‘mantra’ of every good programmer, I had the idea of writing an article about Release smells which would mean something like: bad practices about releasing a software product.
I’ve been working for four years in a company that produces a software product, and my experience as a Build Master is now about two years and a half. My aim now is to give a brief explanation of what I’ve seen, heard, experienced, or did, successfully or not, so that you can learn a bit of my own mistakes and don’t commit them in the future.
The following will apply to products that are delivered to a wide public and where there’s no customer pushing to have the product as soon as possible. This is not my aim here. If you are working long hours to bugfix something for a customer then be patient, get pizza and coke or coffee or Red Bull… and good luck.
So, in my honest opinion, the following are the bad practices that I’ve identified from my experience. Now, when your company or team management wants to deliver a product and it is an internal decision, I strongly suggest that you stay awake, identify the possible smells and protect against them. Your first action should be: warn the management responsible. That’s what a professional should do:
– Okay, you want to release xxx the next yyy, but firstly you have to know that…”.
Many ‘little’ features that are not still resolved
The very same day of the launch (you can extend this smell to x days before) there are many issues that are not closed yet: installation, code obfuscation, deployment, reporting or even testing.
Separatedly they could mean just little issues to accomplish, but there are so many that the whole bunch of tasks becomes a risk that should be identified, planned and controlled.
Take into account your human resources and the time available, make a list of the pending issues, assign human resources and make a PERT estimation (best, worse and most probable). Keep everyone focused on his/her own objective. If the available time is not long enough to finish all the pending details, forget about the launch.
As the deadline is quite near and you have lots of little tasks to resolve, it’s quite probable that some of those tasks are apparently smaller (time speaking) than they actually are.
The key here is:
Are any of those tasks new or unexpected?
Does somebody know clearly how to resolve every single task?
Is there anything that’s not clear enough, or have you got stucked resolving one of the pending tasks?
Does the task resolution depend on someone else (i.e.: external staff, 3rd party vendor, opened support case) to be accomplished?
Do you have metrics about your current status regarding quality? I mean: bugs detected and solved, code coverage, features that haven’t been tested yet…
“The core is done… so everything is done”
Most programmers tend to think that once the main algorithm and main functionality is done, the whole application is done. It’s true that users normally use a 20% of the application 80% of the time, but don’t forget the details: user experience, consistency, documentation, reporting bugs mechanism, licensing and deployment.
If more than one item of the list above has not been accomplished yet, then you are not ready to release.
First alpha release candidate is… a couple of hourse before launching
But the management team keeps on trying to release today, and the team is doing its best to have it ready as soon as possible, closing those little pending issues and… the first release candidate is ready at 2 p.m. the very same releasing day.
Hum, that smells quite bad, specially if you know that there are features not covered with tests yet, because they have been closed recently, in a hurry, and I guess that there was not time enough to write automated tests, am I right?. From 2 p.m. on you’ll have to test the new integrated “little pending issues”. The more they are, the more tests you’ll have to do and the higher the risk you’re carrying on!
The launch is supposed to be within the next couple of hours and we are still bugfixing!
So, the first release candidate was ready at 2 pm., it’s 18 p.m and you’re still finding bugs and building new releases continuously. This is definitely a showstopper.
Take a breath and think:
what was your progress from 2 p.m. till now?
Are there bugs that you’ve fixed and then appeared once again one hour later?
Are there bugs that were supposedly fixed and they still exist in the next build?
Are the people mad running from one place to another and speaking aloud and guessing what’s happening and claiming for a possible solution?
Now stop!! You definitely won’t have a release ready today. You’d better go home, take a break. Tomorrow it will a new day.
If you detect one or more of these problems and you are the ScrumMaster or the person in charge of the project, you’d better to abort the launch. The most probable thing that will happen is that, at the end, you won’t release anything. Kindly ask people to go home and the next day you’ll have plenty of time to try to finish those little issues that will improve the quality of your product.
Ok, you can aduce now that probably it’s not your business to put off a launch, that the customer won’t understand your problems… I have to recognize that this hasn’t happened to me yet.
If that’s the case then try to explain the issue to your customer: you cannot deliver a product with the quality level you’d like to right now. If they don’t understand this, then it’s ok to deliver whichever they want. Try to negotiate a minimum of capabilities, features or performance results. But if they keep on pushing and you are forced to work long hours regularly, you’d better to look for a better job. It’s not worth wasting your time and talent in a company that doesn’t work efficiently and don’t take care of the most valuable part of its business: developers and engineers in general.