Getting It Right the First Time –An Unconventional Approach

Minimizing rework and ensuring polished software releases.

Abstract

One of the most daunting questions in front of software firms is “How to Get It Right the First Time?”
It is important to minimize the rework and deliver good quality software products. In this article, I present some of my key recommendations which could help you come out of the vicious cycle of poor quality software releases. While some recommendations may sound familiar, others may look very unconventional.
The target readers and beneficiaries are the “custodians” of software delivery. These may include the people at leadership positions who are striving for excellence in software delivery.

Why to Deliver High Quality Products the First Time?

So often, organizations accept fixing software defects and non-functional issues as their routine job without giving attention to the high costs of NOT getting it right the very first time. Rework not only incurs various direct costs of fixing bugs & retesting software but also incurs indirect costs such as loss in customer confidence and trust. Below sections talk about some key focus areas which can help you get your act right and ensure polished software deliveries.

Quality Oriented Leadership

Software teams look up to their Team Leads, Architects and Managers for making day to day choices and decisions. They are their idols who give guidance and show them the direction.  At any point, there can be two kinds of messages communicated from the top:

1. Quick Fix Approach Vs. Long Term Solutions
2. Meeting Deadlines at Any Cost Vs. Delivering with Quality
3. Reactive Measures Vs. Proactive Thinking
4. Meeting the Explicit Requirements Vs. Great User Experience and Delighting the Customer
5. Requirements Driven Roadmap Vs. Innovation Driven Development to fix Pain Areas

When there are quality-oriented leaders at each level, team gets the right message of “What holds more value to the organization and what is expected more out of them?”
If you consistently struggle to deliver good quality product releases, stop and check the attitude of your leaders. Results may surprise you!!!

Automation –Focus on Quality Not Coverage

It feels amazing if you show case that there is 70% code coverage for JUnits and integration tests. But ask yourself why do you still miss simple scenarios which should have been easily caught?

Some common mindset issues which are prevalent in the software industry are as follows:

1. Delivering code is more important. "We have an approaching deadline and automation can always be done later." “LATER” never comes, only defects follow.
2. Anybody can write test cases. "We have lagged behind on our coverage; let’s catch these fresh graduates to write some quick JUnits so that we can have that respectable coverage." If people who don’t have necessary skills write your test cases, your team members would be found scratching their heads and spending days just to understand why these test suites are actually failing? Why some test cases were hard-coded to be always successful? Why meaningless test cases were copied between modules without even understanding the intent?
   
   Writing quality test cases involves technical skills. Copy-Paste doesn’t work!! So, one should train their teams for writing good and meaningful test cases. Senior developers must write complete test cases rather than leaving automation to the mercy of new comers.
3. Automation needs less time than development. "When the effort estimate for writing a code is one week, how can the effort estimate for writing it's JUnits and integration tests be more than that?" Constant delivery pressure often leads to incomplete test cases being delivered.

Get your Automation fundamentals right and believe me good regression suites would save you dollars by reducing time and effort of manual regression testing. Moreover, you will catch defects early.

What should be the “RIGHT” mindset?

1. Delivering automation suites is as important as delivering code. Delivery is incomplete without appropriate test cases.
2. Writing quality test cases demands time. We would plan accordingly.
3. Writing meaningful test cases is more important than coverage. Only people with appropriate skills should write test cases.

Decision making- Is it Collaborative or Competitive?

More minds at work means more ideas, more solutions to counter a problem, a better design and much higher probability of getting it right the first time. On the other hand, competitive individuals or groups working in isolation would often miss crucial dimensions of a problem or software design which others could have easily pointed out. Thus, it’s extremely important to gang up against problems rather than using your vital time and energy to gang up against your team mates.

“Everyone you will ever meet knows something you don't.”

                                                                                 -Bill Nye

A collaborative culture is difficult to setup. So, there should be forums and platforms which encourage collaboration and make sure that the very best decisions come out.

Some “Ways of Working” which can bring collaboration in software development are:

1. Platform for publishing design proposals and inviting feedback
2. Formal design discussions and review meetings
3. Forums for discussing pressing problems/pain areas and finding innovative solutions
4. Multiple level code reviews so that defects don’t slip away

Every team member should feel that there is enough for everyone and all of them can succeed together. Fewer bugs, less rework, satisfied customers and more business would only lead to a successful team where everyone is a WINNER.

Break All Layers- Let your Techies feel your Customer’s Business

How often your technical teams visit customer sites? How often your developers interact with your customers? How much your developers understand the unique ways in which different customers use your product?

Organizations may have multiple layers between the Development Unit and the actual customer.  In such a case, developers hardly get any opportunity to see customer business in real time. Developers have theoretical domain knowledge required for building the software, but they don’t feel connected to their customers. They seldom know customer’s custom ways of working, daily routines, implicit needs, unsaid pain areas and priorities.

Often when the product is eventually delivered, it fails to meet customer expectations on parameters such as performance, usability etc. To deliver a wonderful product and deliver it right, you need to FEEL the customer not just work on the feedbacks received via multiple layers!!! 

What will you gain with those customer visits?

• When developers see their products being used at customer sites, they have a sense of ownership. They stop thinking of themselves as workers and instead feel like owners with an attached responsibility.
• It creates an urge in designers to address the customer pain areas on priority
• It creates an understanding of the implicit customer requirements with respect to performance, usability, criticality and scalability.
• Meeting customer rejuvenates your developers and fills them with a spirit and enthusiasm to SERVE customers rather than just do their explicit job and go back home.
• It brings out innovative ideas to fix the real customer problems. 

Don’t Sit on Issues - Log Instantly and Track them to Closure

Many a time, team members come across various product issues and design limitations but don’t feel necessary to log them.  Why to log bugs when testing team is there to report bugs?

This way, you tend to sit on open problems till some fine day your testing team or customer reports the issue. This reactive working style poses various problems:

• Defects are fixed late. This incurs greater time, effort and money to fix them.
• Sometimes, you need to live with defects because the impact of fixing these defects at a later stage is so great that the effort and rework can’t be justified.
• Defects discovered by customers lead to loss of customer confidence and satisfaction
• Vulnerabilities stay hidden. Critical security and other vulnerabilities may cost your organization dearly.

You must understand and realize that reporting defects cannot be limited to the testing team. You must encourage every team member to report a defect, the very first time they encounter it. Similarly, you must encourage your team to log all kinds of technical debt i.e. design problems, documentation improvements, code improvements etc. in some tool. Instantly logging all problems ensure that the problems are prioritized well and every problem is tracked to closure and satisfaction.

In an era where organizations are conducting bug bounty programs and rewarding people with millions of dollars for identifying bugs, you can’t put the responsibility on some testers. What is stopping you to have your internal bug bounty program at regular interval? Have one and you will be surprised to discover your product’s vulnerabilities.

Code Quality is not Optional– Enforcing Gatekeepers

Unfortunately, a bad code could easily accomplish the same job as achieved by a good maintainable code. Thus, functional testing is incapable of identifying bad code.

You should deploy all kinds of gatekeepers to prevent pushing of bad code in your products. Stringent and multiple level code reviews are inevitable. At the same time, you can’t just rely on the individual code reviewers to ensure code quality.

Relying on code reviews is not sufficient. Some facts:

• Different developers and reviewers have different level of skills
• Time pressures and deadlines may encourage code reviewers to compromise quality
• Developers and code reviewers can work for ages and still not adapt many good programming practices. You need Code quality tools which can help your developers to evolve their skills.

You must leverage tools to your advantage.  Tools may include IDE plugins, code collaboration, static analyzers, and Continuous Integration platforms. Initially, tools can be enforced and later the good practices will be in the blood.

----------x----------x---------- 

DISCLAIMER:

The postings on this site are my own and don’t necessarily represent Ericsson’s (or any of my previous organization's) positions, strategies or opinions.