As Belatrix’s developers, we are used to changing projects from time to time. In some instances, this means working on a new project with the same client, or it may mean working with an entirely new client.  Without disclosing confidential client information, I’d like to share some of my general experience from working in software development for the past few years.

Whatever the methodology, good coding practice always requires that the developer pay attention to procedure.  This may sound pretty obvious but it is something that requires continual focus and discipline. Aside from development theory and practice, every project in which I have participated is strongly influenced by people and their customs.  Taking these factors into consideration is important.  For example, it can ensure you don’t overinvest time in dealing with issues, sprint after sprint, when simply following procedures and rules early could eliminate those issues overall.

Some recurring themes include:

User Stories

Writing good user stories is an art. A clear user story pattern, one that all developers understand and can use, should be adopted early. This is a crucial communication tool between product owners and developers and should be as comprehensive as possible, including as much detail as possible. One part that’s sometimes missing is the Acceptance Criteria but given that that informs the minimal set of tests a developer should verify, it is very important to include it. Splitting a user story into tasks is another common source of conflict.  Sometimes tasks are too granular, or too broad. Be prepared to invest some time upfront to define this and get this working properly.

QA and Development tasks overlap

Today’s trend is to reinforce the concept of a “single” team where there is no difference between developer and QA engineer, other than some degree of specialization. Since there are though some specific tasks for QA testing, it is not uncommon to have some upfront questions when planning those tasks: Should there be a separate Sprint for QA tasks? How soon should QA tasks initiate? Should identified bugs be added to the same Sprint or put in the backlog to plan for later? These, and others questions, are good reasons to have a closer relationship between developers and QA engineers and to build in time to address these questions upfront.

Done and Sprint approved concepts

The interpretation of these terms needs to be clearly defined since usually they have different meanings for different team members. It is all a part of defining the necessary “conventions” that need to be adopted in order to minimize “waste” or non-productive work.

Coding style and formatting rules

Sometimes developers start coding without a common coding style and formatting rules. Early adoption of a coding style will improve quality and maintainability of the code.

Development procedures

There is more work to do than plain coding. Most projects include building and deploying applications using some kind of Continuous Integration server(s). Should a new build be started after every commit? Should it be done according to a fixed schedule? Will build be from the trunk, or from a specific branch?

Summary

Finally, all these topics boil down to Code Quality. Focusing on Quality Code always pays off in the end.  For me, as with many other developers, it hasn’t always been so natural to follow procedures and rules in a disciplined manner. Our “creative” side wasn’t happy that way. Now, several years later, I am convinced that procedures and good coding practices have a deeper, longer impact on code quality than having only a bunch of gifted programmers. In a project with a standard to long lifetime, procedures that contribute to implement controlled, iterative, development to create and maintain code quality are the best option.

The challenge for teams is to discuss, modify and adopt standard procedures according to their context, as early in project’s lifetime as possible. While it is easier for new projects to implement good practices, even ongoing projects can benefit from focusing on the role procedures can improve the overall effort.

What do you think?

Leave a comment