Bring CS to SD

We have proven technologies, methodologies, tools, techniques, processes for building successful software products. But many don't succeed in terms of time, cost, customer satisfaction or customer reach because of lack of a simple thing.

Many of you might be thinking it's "User experience", others might say "Quality" and few others could even say something like "Developer competency" or last one could also be "Wrong technology". All of them are subjective reactions once the result is out.

In my experience of close to 15 years, many reasons fall under something as simple as "Common Sense". Lack of Common Sense at different steps and multiple levels would lead to problems that become deep over a period and sooner or later might result in frustrating outcomes for the teams.

In this article, want to share some of those signals and corresponding common sense elements.

Unit tests

• Signal - We plan to write unit tests post feature completion or as a separate user story or as mandated by our quality process.
• Common Sense - Any piece of code that needs to be tested needs to be testable during coding process. So don't say something as development complete without unit tests.

Meeting Conclusion

• Signal - Let's pull Person X and Y to this meeting as they were part of our last design/strategy discussion. Hopefully one of them remember the follow-up actions as we didn't take minutes.
• Common Sense - Lack of minutes in the first place means many things can be messed up in the follow-up discussion. If minutes are not shared, nothing should move to next step.

Code Reviews

• Signal - Our code review process should improve and catch most of the issues from next time. We have lot of tools in place, don't say we have to spend a lot of time to do a good job.
• Common Sense - If sufficient time is not planned for reviewers (including seeing the feature/change in action), reviews could be as poor as click of an approve button which means it's just a matter of time before you hear from customer directly. Then RCA would point everything towards code review process.

Verification Process

• Signal - Our verification team does performance, reliability testing. Development team will apply changes and have to wait for next report to see improvements.
• Common Sense - Developer should be in the thick of action when it comes to seeing how code is performing in different scenarios. If it means developer intends to connect and see system in action, do allow it in the process. Lot of assumptions can be eliminated if this is enabled.

Acceptance Criteria

• Signal - Retry mechanism or Logging related details are not mentioned in the acceptance criteria or not discussed in the feature grooming.
• Common Sense - Core developers are meant to deliver these aspects without the need for specific inputs. Figure out if it's lack of discipline or motivation.

Technical Debt

• Signal - This framework sounds good. We will add it to technical debt and check the feasibility in one of upcoming releases.
• Common Sense - It's as good as passing the buck to someone else. Try to plan feasibility at the first possibility. Then figure out which release based on the outcome.

Early Feedback

• Signal - Let's protect our idea and only show it to customers when we are ready to launch.
• Common Sense - Best way to protect an idea is to get buy-in from customers. Involving customers during development process makes it a possibility.

Estimation

• Signal - When you estimate for this spike, keep an eye on our 2-3 weeks schedule. We have to try our best not to impact our sprint objectives.
• Common Sense - As a team, focus on the scope and estimation at hand for the spike to get it right. There are bigger objectives beyond couple of weeks that every team should strive to achieve. Those objectives are the ones that keeps customer use your product.

Prioritization of Bugs

• Signal - We can analyze this bug if priority is agreed upon.
• Common Sense - To discuss priority, it makes a lot of sense for core developer to do first hand analysis. If it's straight forward and has impact on the product or end-user, just fix it.

Secondary View

• Signal - We have to plan some peer testing sessions to avoid issues being caught by testing team.
• Common Sense - If you are a core developer, request some peer testing (could be a Developer or QA engineer or Architect) to ensure major things are covered. It's a cultural thing, if everything needs to be formally planned and peers doesn't think or look beyond their work.

Documentation

• Signal - Document things (Ex: Customer feedback, Issue analysis, Alternate approaches etc.) whenever you get free time.
• Common Sense - Documentation is the only way that knowledge stays in the team even if a person moves or leaves. Plan it as a deliverable and that's the only way to do it.

Specific Roles

• Signal - For short term, we will ask new developer or intern to write integration/installation script. That ways we have some work started to save time and someone can take it forward.
• Common Sense - If that integration/installation has to be done on customer environment as final step, avoid making poor foundation. Specific roles are identified for a reason in software development.

Once signals are recognized (not just above but every relevant one), common sense can be implemented in many ways.

Common sense in an uncommon degree is what the world calls wisdom.

Hope this article brings a new perspective and provides some insights on how common sense can eliminate core issues that could become deep problems within the system.

Thanks for reading. Do share your valuable feedback.