A Radical Way For Better Software Development
Help yourself build a positive mindset in sake for high quality software development process.
A software development is a long, hefty, and complex things to do, especially for a custom software development that need to be done “perfectly fit” for the client needs.
Engineers sometimes also stumbled upon the difficulties while implementing the technical specification or the UI/UX that already designed and approved.
Richer features mean higher complexity. The higher the complexity exist, means that there are bugs or errors that may exist on the application that under development.
A question raised. Can I develop a “perfect” software that so flawless it don’t need a future development?
You can’t.
The Perfect Software
Many tools, libraries, and frameworks exist out there just to help the engineers to build the software. Using a specific of those doesn’t mean you could get a “perfect” thing. The output really depends on whose built the thing, the engineer itself.
You may don’t feel highly motivated with my word above if you use or develop a simple app. But trust me, building a big or complex software project would kill your ass just to release a single, stable, production-ready version.
There is no such thing as “perfect” software. The only you get is a “usable” software. As engineer, you may found the majority bugs or errors that have been found before release, but you may never know the app that used by client still have hidden flaw. Am I right?
Many of the engineers try to hunt the flaw by manually testing the app, using separated development environment, and even writing some type of unit tests. But still, a single point of error could destroy a whole workflow of an app.
The failing background job, poorly-implemented UI/UX, high traffic load, and other infrastructure problem are some of those. Not to mention that human-error can affect the app usage too.
Some development agency tried to prevent this by using multiple development channels, e.g. Staging, Canary, and Production, to separate the user needs and hopefully prevent error unintentionally delivered to them.
Therefore, “perfect” is too fancy word to be used here.
The Bugs
This is the most hated thing among many engineers. Usually existed as a flawed feature, unintended code or process that mistakenly released and used by the end-user.
Some are minor, some are major, and some can give huge loss and harm the users. In fact, many of those flaws can even end a human life.
The documentary above tell a sad truth story, when a programmer’s flaw can unintentionally ends not 1, not 2, but 6 human lives. Of course, the program, or system that developed already tested carefully, passed several quality control tests, and even certified by legal authorities.
But still, undetected flaw can be shipped to user unintentionally.
More engineers, more success?
As the problem described above, now a final question raised. How to develop a software with a better quality than usual?
The important thing you need to know, software development is a continuous process that takes a lot of time and money. Of course, more time and money would make the software better.
Another thing that should be noted is that more engineer hired in ongoing project doesn't really make the development faster. Respect the Brooks’s Law.
Adding manpower to a late software project makes it later — Brooks’s law
With the long development timeline, engineers should be able to withstand a lot of pressure and think many solutions regarding a complex set of issues. There are times whether they can’t even handle the flaw of product that made by themselves. This is normal and happened to many development team too.
Many of the team or agency see a bug or error as a shameful flaw that the engineer need to be blamed because of the inconsistent work. Giving them a warning is okay, but blaming them will just add a pressure over their head.
How do we fix this?
Error as a Value
A simple approach for this is just to build a positive mindset about how we encounter a flaw, no matter it’s a bug or error. Instead of assuming that the bug / error found is a flaw, we mark them as valuable founding.
By doing this periodically, the team and engineer itself would value the bug or error that found by any person, rather than blaming each other about whose cause that flaw.
Record the founded bug / error to the ticketing system, give them proper ticket priority, detailed description, and some way to reproduce it so that the engineer who assigned can fix it as soon as possible.
Always trust the engineer. Trust is the only point here. Of course, a professional software engineer wouldn’t let a product they made become full of flaw and ended in failure. An unintentional flaw that exist is not fully their mistakes here.
A reported bug should be marked as regular work, and not a debt.
Always give a time margin to fix the bug / error in each development process. Your development plan is a happy flow that your team want. You don’t know what’s going to happen in the end of timeline when your app going to be released.
Before you go
The last but not least, feel free to open a discussion or ask anything in the comment section. This is a pretty interesting topic to talk about, haha.
