Today I want to talk about a reality that clients wish wasn’t there. Specifically, bugs and their apparent prevalence. The problem has 2 sides. On the one hand, we as developers overuse the word “bug” to describe many situations which are an inherent part of the development process, leaving clients thinking there’s a problem when there isn’t. On the other hand, clients themselves often over react to bugs, holding coders to a higher standard than almost any other type of development work.
Bugs everywhere
Let’s be honest, I have never created any website, application, or piece of software that didn’t have “bugs” on some level. It doesn’t mean that I’m a bad developer. It doesn’t mean that the people who work with me are bad professionals either. No, bugs and technical issues are a common part of software development and release. We need to understand the reasons they appear and make our plans accordingly.
Recently, I noticed a major bug on the Facebook app on iPhone. It was lying right on the surface. Two tabs which should display different information both showed the same thing.
If even one of the biggest tech companies in the world, with over 25 000 employees has simple interface bugs in the production version of their app, the rest of us should avoid kicking ourselves too hard when similar slips emerge.
How should we understand references to “bugs” and an approach to dealing with them?
I believe that first of all a distinction has to be made between bugs that occur as a natural part of development and bugs that come about through carelessness or sloppy work. If a bug appears because a developer consciously chose to ignore or disregard an issue flagged during development, that obviously constitutes a serious problem. Where bugs appear as part of the development process though, this is expected, natural and can be planned for to some extent. Perhaps we shouldn’t call such things “bugs” at all!
Speed
I assume you’ve considered before now the trade-off between cost, quality and speed when it comes to project delivery of all sorts. You can’t optimize all 3 at once, you have to choose which 2 are the highest priorities for your project and run with that. If you want to strongly prioritise one area, both of the other areas will take a hit.
A lot of the clients we work with are startups. In their case, speed is the highest priority (and in a large majority of cases cost comes second as they’re bootstrapping or building off of seed investment). Their main aim is to build a minimum viable product and get it out on the market as soon as possible to test their concept. This is absolutely the right move for them, but given this emphasis on speed, they should understand going in that the end result will have some rough edges.
Actually this approach has been behind a lot, if not all of the major technology businesses that loom large today. Speed of production and putting an MVP on the market as soon as possible are the main focuses. Not maximum perfect product, but minimum viable. Then you’ve got something solid to take to potential investors. More polished iterations and scaling come later.
Because we’ve done it many times over, both for clients and for ourselves, we pride ourselves on being good at that low cost, high speed, MVP delivery. That’s why I’m confident in saying this, not just as a nice theory, but as a proven strategy. Once you’ve got your MVP, you can prove or disprove the startup’s hypothesis, and use that as the basis to raise further funding and develop your ongoing strategy.
For a long time our major startup Kidslox couldn’t do some seemingly basic things. We had zero marketing budget for example, and an extremely limited feature set. But we had a couple of core features and they were helpful enough that the users were willing to overlook the occasional glitch. This was the evidence we needed that we were onto something, which propelled us to where we are today.
On the other hand, we have had clients who developed their MVP for over three years because they insisted on getting everything perfect before releasing. The product never went to market. Whenever it approached being “ready” the whole market shifted or another competitor filled the space and they wanted to keep developing. For better or worse, speed is the highest virtue when it comes to new tech projects. And as Mark Zuckerburg implies with his famous motto, when you move fast, things break.
Must have bugs
In many ways, software development is like real estate development. At Ekreative we’ve been in the fortunate position of needing to build two new offices as our company has expanded. They’re built on the same plot of land, and as we built them, I saw that the principles that apply to development are universal, whether it’s software or construction.
Before we built the second office we had a wonderful grass lawn out front, that we took care of and had team events like bbqs and picnics on. When the huge trucks came with materials for the new office and started digging the soil and pouring concrete, they completely ruined that lawn. There was nothing left of it and once the work was done we had to redo it from scratch.
That’s an example of a natural, “must have bug” of the second office’s construction. There was no alternative. The trucks couldn’t just jump over the grass. Everybody understands it. In the same way, we need to show our clients that there are certain things that will always happen during development. They’re inevitable and might be better thought of as software deployment optimization than simply bugs.
If you’re building software for a very structured corporate client with deep pockets, they might have a roadmap planned out with a well milestoned schedule for the next couple of years. In most case though, even corporate clients aren’t in this position, and for startups it’s out of the question. Usually the client doesn’t have a 100% clear vision of where they’re headed when they begin development. Even where the plan is incredibly solid, it’s impossible to predict all of the obstacles that will appear during development.
A good software development company has to be always ready to adjust, be flexible, pivot, and make necessary changes along the way as plans change and unforeseen challenges crop up. Obviously, the consequences of such changes are that some things break, or need to be redone. We need to avoid falling into the trap of thinking about this work as “bug fixing” though. These are not bugs, they’re essential optimisation made necessary by changes to the scope. “Change request optimization” if you will.
The only alternative to carrying out this optimisation is to plough on with the agreed upon scope and say “no” to the clients requested changes. Obviously this is not an acceptable move in an overwhelming majority of cases.
While it might be appealing to stick strictly to what we planned to do in the beginning, once the need for change is evident, the only responsible route forward might involve taking a few steps back. Obviously we can try to limit the number of these sorts of changes through thorough planning, estimating and assessment of the scope, but as the project progresses, small decisions made at the beginning of development can have big consequences further down the line, and if the client decides that those consequences aren’t acceptable, they might want to request changes. But these changes and any initial incompatibilities arising from them are not bugs.
Expectations
Sometimes when we finish a project, despite familiarity with the design, wireframes, regular updates, test versions and more, the client seems surprised by the end result. They never quite had a clear picture in their head of how the end product would look, but assumed it would be somehow different to the versions they’d been seeing during updates. Once they realise that this is it, suddenly a greater clarity about how it ought to look appears and a series of change requests are made. This is not an unusual scenario, but again these changes aren’t bug fixes, though it might be tempting to think about them that way. They’re more like the finishing touches to a fancy dinner preparation. Without them the food would still taste good (the product would still work as planned), but it wouldn’t give the exact impression that the chef was aiming for. These last minute additions and edits are part of the development process though, there’s no “bug” to be fixed.
No project is ever completely finished. It’s the way of life. Buildings always seem to need maintenance, extensions, redecorating, etc. People and society change constantly. Software is the same; as technology, the market and society shift, software requires maintenance, updates and adjustments. What we call these changes matters, so please, don’t mention “the B word”.