5 Secrets to Quality Software Delivery

Quality Software works as expected today and can be easily modified 6 months later. How can a team consistently produce software with a high level of quality? In other words, how can we as software development professionals 1) fulfill requirements through working software and 2) ensure that our code is maintainable by others late on? Acklen Avenue does this on a daily basis and has, over the years, discovered some repeatable “secrets”.

Manage client expectations

The client’s perception of the quality of your software is what decides the level of quality. If they feel like they’re getting a raw deal, then it ruins any effort you have made to maintain high quality in other areas. The #1 most important key to delivering high quality software is “managing client expectations” regarding doneness, timeframe, and cost. You can deliver the highest quality piece of code ever written, but if it is delivered late, costs more than budgeted, doesn’t meet client desires, and the client was not prepared – then everything you did (great or not) is colored by a bad perception. Perception is reality, therefore you failed to deliver high quality. On the other hand, if the client is 1) well informed from day 0 (way before the project starts), 2) they know what to expect every step of the way, and 3)they have had a hand in deciding what to do when a feature is discovered to be underestimated, then your clients favorable perception will allow the quality of your delivered product to shine through.

QA on the Heels of Devs

For those who get to work with a great qa team, you know how great it is to get real feedback on your work and bring it closer to the definition of “done”. But most qa teams work as a separate unit from the devs and they seem to test things days after code has been written. It’s a proven fact that, the longer an undiscovered bug or misinterpreted requirement (considered a bug by the client) exists, the longer it takes a dev to fix. Traditional QA teams are not included in planning discussions and are usually left out of the development process. For this reason, most QA teams are several steps behind developers and fight to constantly catch up. When QA gets behind, bug lifespans grow. To meet deadlines, some bugs are allowed to continue unfixed. Others get hacked. Quality software is software that works as it should: 1) according to client desires, 2) low occurrence of bugs. Even the best qa team can hold up the discovery of bugs, then in turn, damage the quality of your software. On the other hand, if qa is proactive and works “on the heels” of developers to test new features, then the feedback cycle is quick and cheap in terms of time, money, and frustration. Quick feedback allows devs to react while their memory is fresh, fixing bugs much faster than days later. Not only does the software work the way it should, but it got finished faster. For this to happen, it’s essential that the team have sufficient QA resources, and that they work closely with the devs ON THE SAME TEAM and share the same goal: flawless delivery.

Principled Engineering

You never know how well a house was built until you try to add on a second floor. Likewise, the most neglected component to software quality goes unnoticed until the client tries to modify or add features to his software. All devs have seen it. Code that only a mother could love. The original developer can hardly work efficiently in the code base a mere 6 months later. Spaghetti code. Poor architecture. Technical debt. The software meets original requirements, but can’t be modified without great expense. This often happens because developers, though smart, are not always principled. For whatever reason, be it a close deadline, pressure from leadership to take shortcuts, or a general lack of experience… They don’t follow standards. They don’t use patterns. They make rash decisions in the name of quicker delivery. Though the software is high quality in terms of meeting original requirements, it is low quality when it comes to maintainability. On the other hand, software developers who produce high quality code put forth extra effort in how they leave their code. Many principled developers consider future developers while writing code. They think of how other developers will read and understand. They use standard practices, patterns and techniques rather than clever inventions. Principled devs take time to consider the impact of their decisions on future maintainability. They also stand up for their principles when leadership tries to force them to rush through a feature. Code flowing from a team of principled developers is higher quality because it is ready for changes.

Deliver on first day

Delivery is, many times, an afterthought, or at least something that is saved for last. Just before the end of product development, dev teams scramble to start deploying and integrating with client servers. Any wrong assumptions regarding server technology or environment type get dealt with using hacks or bug fixes. Hacks are hard to maintain in the future and produce more bugs/hacks. Bug fixes cost more and more as the bug is allowed to exist undiscovered. Software quality is defeated by bugs, cost, poor maintainability, and extra time spent on problematic deployments. In fact, the average team spends an extra 1 to 2 weeks deploying and integrating when the project is finished, plus as many as 10% more integration-related bugs when deployment is saved for last. How does the client feel? On the other hand, most delivery related problems and their ill effect on quality can be averted by early and frequent delivery. In fact, the best results come from teams that deploy from day one and continue deploying to the client’s server (at least) every sprint demo. With the help of tools like “Continuous Integration Servers” deployment can be as easy as merging new code to the client’s code repository. Early and frequent delivery helps raise the level of code quality by giving developers early warning of environment based bugs as well as helping the dev team deliver the product on time.

Dedication to the Demo

A distant, massive goal is harder to attain than a close and clearly defined goal. Any software developer on a project would agree that the goal is to finish. But, just like any large task, it is difficult to maintain focus on the overall goal when there are so many smaller tasks to accomplish. Sometimes we say that people “miss the forest for the trees.” With software development and so many incredibly complex and detailed tasks, it’s more like we “miss the forest for the leaves.” Agile methodologies like Scrum tell us to split the work up into short loops, starting with a defined set of tasks to complete, and ending with a demonstration of the work that got done. This is exactly what software developers need to stay focused on bringing value and high quality to clients. But we shouldn’t stop at just showing what was done. The entire team should consider the demo as the sole purpose of the iteration. Every decision and action should be made in order to ensure the success of the demo, even the tasks chosen in the planning process before an iteration begins. Each demo should be spectacular and flawless, demonstrating the elegance of a complete set of features. All feature development should be focused on demo preparation. QA should be checking unit of work as if the demo depended on it (it does). The whole team, from project managers, to business analysts, from programmers to testers, shouting the same battle cry: “Demo! Demo! Demo!” This has a profound impact on software quality. From demo to demo, your team will deliver awesomeness.