Many people will tell you that software development should tend to deliver a product that is as bug free as possible. Many experienced developers will tell and proof the opposite: bugless software development is impossible. Software development is a process that consists of 40% development and 60% managing all the necessities in time and place. The struggling of the developers most often sums up in either making good solutions that are technically usable, flexible and easily maintainable or in making all other side-things work except the thing the developer should focus on most: the development. Developers that tend to bring bugless software in short span will have the problem to solve much bigger issues later: why is this done the way it is, why this code is not reviwed, why is this code duplicated, etc. Whoever asks from the developers build software without bugs, either has great plan to achieve this or is clueless into developing software.
When talking about business it is more than important that there is as less development included as possible in the process, and having good percentage of development savings from previous projects. So yes, business models are in collision when it comes to the quality of the software. Businesses need fast but quality developed software. And that is almost impossible. It’s because smaller businesses involve smaller budgets for smaller projects. And small budget has large impact on the quality of the code and the project in general. The methodologies, the scopes, devices and other side-constraints make the development of bug-free software even less possible. The business needs you to develop the project yesterday so that when the sales person goes and sell it the software works as it’s required 100% (which is again: impossible), and you need the time to focus on the development and create less bugs for the quality assurance phase. Well, that is when the problems appear again. Most of the companies do not have QA phase in its development. You want bugless software – you need bugful QA phase.
Now ask yourself a question. What was the budget for the last project you developed but turned out disastrous failure when it comes to being buggy and laggy and succky? $10k ? 20? Ok.. now let me say that this budget is something that would make the project durable for 2 years if the team consists only of 4 people whether that period of 2 years is spread in 4 years span or is continuous with total time of ~480 working days. Yes, that is something that will keep the project in good shape only in that period. After that – either find another investor, add more of your money to the budget or close the project send the developers home (there is great possibility that they have other great ideas in mind). Smaller projects have bigger problems because most of the time they are underestimated, forgotten (then revamped), cut in the middle of the development (as in: we cut the QA phase, we cut the polishing phase, etc.). Then if you discontinue the quality assurance phase please never ask from the developers why there are this many or so many bugs in their software. It was their goal what you told them to: bring the software until that date so that your face doesn’t turn red when you try to sell it, bugfree software development was never theirs goal. They did it and the software sucks. Yes, it sucks because the business model cut all other parts of the development. What left now to do is take your undeveloped and misunderstood development methodologies and find a clever way how to make what the developers were supposed to do at first: put emphasis on the quality of the code, the work, if needed mentor less experienced members of the team, review and refactor their code, etc. Be happy that at least one of the conditions for the software being developed is met: your deadline. Be sad that you didn’t provide enough time for other experts to find as much bugs as possible. Cause to err is human, luckily in software development these errors are fixable and manageable.
But why are bugs healthy you say?
As said already, it’s in our nature to make errors and not being able to resolve or predict all possible results out of one’s action. And when someone finds mistake in what we do, we should rejoice for we have chance to fix that error before it goes into production. And yes bugs are something that teams should learn and not be ashamed from. Or god-forbid put in the shooting field by their superiors. We learn new things ever day and the most important thing we need to do in the process of development (besides having common sense with the whole team) is be yourself in the field you’re familiar with. Business is not your field? Do not take part of those processes. Development is? Go for it and keep your side. Those people that find you bugs are your friends and they love you. Probably.
Software development is one of the most fascinating things in the modern world because of two reasons: you create things that do not really exist out of nowhere and (no.2) because there is great possibility that you (the developer) is part of the 1% minority of the population in your area that understands what that code means.
Trying to finish this column by quoting a comment from Stackexchange:
Good design practices, good control practices, good teamwork, conscientious developers – that is the formula for good software. Not perfect – but good.