I read an interesting blog entry by K. Scott Allen regarding software development "Never Events". I thought this would be a good subject to bring up in this forum. For this particular question I would like to focus on the "Never Events" that are the most important to avoid in a software development project. Please answer with a single "Never Event" per answer so that we can see the most heinous events bubble to the top.
Never events must be
"Let's get the prototype ready, the design document/UT can wait."
Releasing something that has not gone through QA.
I most often see this happening when the development company has signed a contract to pay a substantial fine if the software is not delivered on time. Usually such contracts don't explicitly define the quality level or content of the deliverable, so the easiest way out is to deliver a complete mess without daring to consider the backlash.
We could patch and release without testing if that would be quicker ...
Releasing code immediately before a business critical time, ie Christmas for retail, or exam time for education.
A client of a brokerage house should never log into the web site with their userid/password and see someone else's data.
Of course, this applies to a lot of other businesses, too.
Using timestamps as a means of versioning .NET assemblies.
Releasing a "quick" bug fix to a live system during heavy user load without proper testing.
The deployment of a product is not performed by the team that created the software, but given to someone from another team.
(Happened to my boss this week...)
Documentation for the code ?
What for ?
The code is clear enough to be self-documenting... ;)
In the style of the linked article where mistaken identity (of body parts, people) features heavily
Never perform an action on a production box thinking it is Test/DR.
This means:
"In order to begin to develop on the source code you need : install a website by copy/paste on your machine, create a new database, change your config file, create a directory in this and this directory, set another directory in read-only, install this product etc..."
Keep it simple ! A script should be present in the SCC to set the dev environment in one step.
Making manual configuration changes to builds for different enviornments..
The never-ending crunch mode. See e.g. the "EA spouse" story.
Even in a healthy company people must sometimes put in some extra effort and work overtime. This can be a good thing that strengthens the team spirit if everybody toil together, beat the deadline, and can then go home and get some rest.
But when everything is critical all the time, people stop caring and become less efficient than if there were no deadline at all. The worst way of doing this is moving people from one project that's just ending its crunch into another project that's just beginning its crunch.
Make no effort to perform sufficient business analysis and keep the business engaged thoroughly from initial design through support and beyond.
In fact, don't require developers to have any basic understanding of the domain they're dealing with either. They need to be good at zeroes and ones and that's all. And the business people don't have to be stakeholders in the design, testing, and support of the system, they just need to do their business and that's all.
Failure to focus on the customer(s).
It matters not whether the customer is:
This does not mean the customer is always right. If you think they are wrong feel free to talk to them and see if you can improve but you should talk to them and listen to what they have to say.
You can deliver the most robust, wonderful, brilliant, elegant system which is utterly useless to the people for whom it was intended. IF you cannot repurpose the solution to another customer then you have actually done worse than a quick and dirty ineffective solution since you will have wasted more of your and the customer's time getting to the same (non functional) point.
If you have multiple differing customers the general advice still holds true but then the subjective (and possibly political) elements specific to that situation mean it's much too complex for a 'Never'.