In a perfect world, all software would deliver excellent user experience, be free of bugs, never crash, do what you expect, and just work well.
This is not a perfect world.
There is a huge range in terms of the quality of software that is written and released to users.
I love to praise software that works well, and curse software that is doesn’t work right or as expected. More and more, though, I’ve been thinking about what causes software to end up either “good” or “bad”.
Why Most Software Sucks
On one hand, I completely agree with the assessment that We Make Shitty Software.. With Bugs!
I argue that there are two main reasons for bad quality software:
- Bad Developers & Designers
- Business constraints on budget & time
For this article, when I talk about software quality, I’m referring to what a users experiences – not the source code quality. I’ll talk about code quality towards the end a bit more.
Bad Designers & Developers
Even most mediocre designers & programmers should be able to produce decent quality software given enough time.
I’m not a graphic designer. I could probably produce some good graphic design for a website if I had a lot of time to work on it. I’d need to review a lot of examples of good design, learn a graphics program well, and go through a lot of trial and error. Ironically (or maybe not) I’d probably try and find some good designers to help me if I wanted to speed up the process. However, this would take a long time. Also, no one in their right mind would pay me to do it, as it would be much cheaper and faster to hire a good designer.
A similar thing goes for programmers. I’ll bet most mediocre programmers can create a piece of software that is free of major bugs, performs decently well, has good validation of user inputs, and behaves as expected. However, it might take them 10 times as long as a better programmer for the same level of quality.
If your designers or developers are bad enough, then the amount of time it would take for them to produce good quality designs & software would probably be so long it would be ridiculous and impractical. In this case, you’ll always be settling for whatever crap they can produce in a reasonable amount of time.
Budget & Time Constraints
Even if you’ve got great programmers & designers, it still takes them a good amount of time to produce high quality software.
It is extremely hard and expensive to produce very high quality software, with excellent user experience, that works on all platforms that a user tries/wants to run it on, and behaves the way a user expects throughout.
For most businesses (and products) this will remain a fantasy. But this doesn’t mean your product will fail.
Look at Words with Friends. That app is and has always been buggy as hell, has pissed me off repeatedly, and I’ve sworn out loud, “This app is a buggy piece of shit.” However, I kept using it. Tons of people keep using it. Zynga bought the company that made it, and Zynga is now valued in the billions. But I digress …
You want to focus on creating something creates value. In business terms, your market is the most important. If they demand bug-free, very high quality software, and it will be profitable for you to make it, then you should create just that. But if you’re in a hurry, short on cash, and just need certain features to work well, then it’s OK to take shortcuts. The perfectionists (like myself) will still bitch, but who cares about them anyway ;–) As long as they’re the minority.
The biggest advice in this area that I can give is that if you are the one making the budget & scheduling decisions, make sure you know exactly what level of quality you want or need and figure out what it will take to reach your target in terms of money & time. Of course, a couple of caveats:
- you’ll probably need a lot of input from your developers & business analysts on this if you’re just managing the project
- it will probably take a fair amount of experience to get it right
- this is much easier said than done
Setting up a good development infrastructure can help a lot, but it also takes time (and therefore costs money).
Code quality does have a direct effect on external quality for several reasons:
- badly written code is more likely to contain bugs
- bad code is harder to maintain, meaning it’s harder to implement new features:
- due to time & budget constraints, half-assed solutions will be put in place because doing the right thing literally takes too much time, is too risky, etc.
- a bunch of time is spent fixing stuff that gets broken while trying to add the new features, or trying to figure out old code, instead of focusing on getting the new features right
I am much more picky about the quality of my own code (and other team members code) if:
- the software is going to end up in production
- it has any potential of being long-lasting
- the code will be developed by anyone other than myself
Good testing is related and can help quite a bit as well.
Learning to write good quality code takes time (or at least it did for me). Although I’ve always been able to solve complicated problems easily, my solutions were not always the prettiest code. The first site I wrote in PHP makes me shudder when I look at it now. I wrote really crappy code. I could have written good code, but it would have taken a long time to produce something that worked if I’d taken that approach before having gained the experience & skill.
I still succumb to pressure from business objectives, and take shortcuts to ship code. I try to leave FIXMEs behind, so the next person at least has an indication that something should be fixed at some point, or that I wasn’t totally clueless and just forget to fix something.
When I look at a piece of software, or when I’m reading through another developer’s code, my natural inclination is to critique and judge the code. Although I still do this, I now try much harder to give the developer the benefit of the doubt, and figure that business objectives could easily have had a direct impact on the software quality. Until I’ve worked with the developer over a period of time, it’s too hard to say whether they are a bad programmer, or had to bow to budget & time constraints, or both.
Contract & Freelance Work
A quick word about freelance & contract work.
If you’re doing fixed-price, fixed-scope contracts, be very careful about making sure you get good quality work. Unless you’ve got a good programmer reviewing the code, and a satisfactory code review is part of the contract, you may end up with something that stinks under the hood. Maybe this doesn’t matter.
On the flip side, if you’re paying for or doing hourly work, be very careful about unnecessary work. Break down features & work as small as possible, define explicitly in writing (after real-time collaboration) the minimum functionality for a feature as a set of Acceptance Criteria. Then make sure your developer does only the minimum amount of work to accomplish the goals, while maintaining a minimum level of code quality.
In both cases, make sure you have a good Definition of Done that applies to all of the feature work to be completed.
I am still passionate about high quality software, but i also have come to realize why not all software is high quality, or necessarily needs to be. Better quality software will always evoke a positive emotional response with me, while lower quality programs will annoy me and cause me to utter profanities. Oh well.
I think good developers should push good coding & design on whatever project they work on. Really good ones with integrity and enough balls (or enough other opportunities) will refuse to create or ship code that isn’t awesome.