No doubt you have heard of Lean Software Development Agile and this DevOps stuff, well, it doesn’t work. Bloat Software Development is the way of the future.

In this post, I will go through the 7 key principles of Bloat Software Development and you can happily delay your projects indefinitely.

1. Incorporate Waste – This isn’t as bad as it sounds. You are not systematically trying to delay by slacking off. No, you delay by adding manual processes (If you haven’t got a process for adding a process, you need one), increase lead times, do incorrect work or add unrequired features. Also, don’t forget to document everything up front. The more pages the better. There is nothing like a 700 page requirements document that says nothing about the end product. Automation is good too. Have a task that will save you a small amount of time, automate it, but spend 18 months for its automation. 6 months sitting on it(we should automate that), 6 months development, then trying to perfect it for another 6 months before releasing it to your development team (if ever).

2. Check Quality at the End – You have to make sure that everything works right. The best time to check quality is after development. Hand off the finished product to the testers. Make sure that the testers have no idea what they are testing. (See principle 3, obscure knowledge) and hand back a bunch of defects back to the Developers. After a few rounds of this cycle, you will eventually go to User Acceptance Testing, only to find out you have built something completely different to the customers requirements. You will then either go back to the drawing board, or the customer would have spent so much money that they will need to accept the final product, with a few major changes.

3. Obscure Knowledge – The whole idea here is not to lie or mislead, the whole idea is to describe the requirements as vague as possible.

One of the keys to obscuring knowledge is cyclic logic.

For example:

The purpose of this requirements document is to fulfill the requirements of the feature. The feature will fulfill the requirements as specified in this requirements document.

A true master of knowledge obsuration can make a document flow, without actually saying anything.

4. Get Commitment Early – Oh yes, we have have that for you in 12 months. When the 11th month comes along, then you let the customer know about the delays. Sorry, we have only just finished writing the requirements, it will take another 6 months. 5 months later. Sorry, development has been delayed, you have changed the requirements based on the original requirements document, it will take another 6 months…… You get the drift.

5. Deliver Eventually – That is unless the project is canned before it is completed.

6. People are Resources – You can chop and change people at any time. They are mere cogs in the machine. Add more people when deadlines are looming. Work your people 24 hours a day. So what if they are exhausted, sick, tired. They bounce back. If they don’t – replace them.

7. Optimise the areas of least return- If you have a task that takes 10 days out of a 12 month project, and you automate it (while having a single resource for 6 months working on the automation) so the time is halved to only 7 days, it is well worth it.

/S

As much of a joke that this post is, sometimes some of this can be seen as the norm.