Maximizing Quality and Quantity in Software Development
We all want more- more time off, more money at work, more wins for our football team... it's in our nature. In software, it's important for us at GRS to remember to balance wanting more speed and more work with the quality standards that we've adopted or we're going to have fewer customers.
Most measurements of software design as well as any other job are taken in volume of output- how many buildings a construction company builds in a year, how many patients a doctor sees in a day, or how many websites or apps a software developer produces in a month. However, targeting these three measurements in their respecrive industries can easily lead to terribe results. If a construction company builds ten buildings in a year, and even one of them collapses in twenty years, that company would be out of business very quickly. Similarly if a doctor can see ten patients a day but five percent of them end up in the hospital for what they came to the doctor about, that doctor would be called a quack.
Software developers also have expecatations placed on them by their employeers and by customers about how quickly they should work, and of course these are reasonable. We can't tell our customers that their two page website will take somewhere from a week to a year to deliver. However, just like the doctor and the construction company, our work is judged initially and over time, and it's crucial to offer the speed of our competitors while making sure we also offer the reliability of companies like Apple and Google- both for the sake of our customers and ourselves. We don't want for our customers to wake us up at two in the morning because their storefront app isn't taking orders any more than our customer wants to miss out on hundreds of orders because of the outage.
As discussed in our post on The Good and Bad of Agile Software Development, the strength of Agile- quickly showing results to customers- can quickly become its achilles heel if quality isn't given the top priority. I worked at a popular website sharing rates for mortgages, credit cards, etc. Management learned about the Agile movement and thoguht that they'd take some of the principles that they liked- short daily status meetings called standups, breaking work into small chunks with short deadlines, and putting documentation off until necessary- and leave out the parts they didn't. It turned out that, as tends to happen, management saw this as an excuse to try to squeeze more out of their developers and shortened deadlines. The first development cycle resulted in a few bugs that we should have caught, so working on those in the second cycle of course rushed our development... by the third month we were only working on bugs, and we looked incompetent to our customer.
This TED talksums up the issues that programmers often lament about a traditioanl work environment. Henrik Warne has a good WordPress article on how to increase developer productivity, and we largely agree with and practice his ideas. The ideas boil down to the concept of avoiding interruptions with a few exceptions. Status meetings and meetings in general, changes in priorities, and showing up to someone's desk with a question that could wait for an email response are examples of interruptions that can break a train of thought. Those interruptions that save time overall are exempt- even though answering a customer issue or being asked how to code something might make one individual less productive, those things making the team overall more productive mean that they're encouraged.