We are here today with two developers who have been working different time frames within the same project.

The project was for one of our biggest customers and as such, it was heavy on processes and organization. That’s what it takes to organize a big project around the principles explained in our Making Sense Development Process Series.

The Making Sense Development Process in Action

We thought it would be interesting to examine whether and how the MS development process truly worked in this scenario. The best way, of course, was to speak with Daniel Altamirano and Diego Camacho, both Senior Developers with background in .NET Backend technologies.

They have been sharing their experience in this project for six months, although Daniel has been part of it for about a year and a half.

The Challenges they Faced

One of the many aspects of software development has to do with adapting to the details of each project and of each client, that makes it work smoothly and drives it to a successful completion. On this regard, both Daniel and Diego shared their insights and experience.
For Diego one of the main challenges was adopting tools such as Git Extensions, Bitbucket, Jira, KDiff3, etc, since his background was with Team Foundation Server.
Fortunately, he is happy with those tools and work with all this world out of Microsoft.

Daniel, on the other hand, remembers having some issues with the code reviews. He performed various changes that, though beneficial, had nothing to do with the ticket being tackled at the time. This made him become more thorough about what he committed and how, in order to help his coworkers review the essential bits.

The underlying cause for this was that on big systems such as the one for this project, there usually are many pieces of code that can be improved all the time, while we’re trying to focus on solving a specific issue that forces us to modify several modules. It’s always positive to be able to add more value to our work, but it can be a daunting task for our peers that need to review our code. This can be mitigated by separating the opportunistic improvements on a different commit (regardless of whether they go in the same pull request), so the specific code for the ticket can be reviewed separate from those bits.

Keeping track of progress using Jira was another difficulty. “Being on the maintenance team, we often needed to switch priorities to take care of tasks that were not the ones we planned to attack during the sprint. As Joel Spolsky wisely puts it, human context-switch is harmful when we’re talking about productivity. Add to that the task of remembering to log how much time you have dedicated to each one of them; and you better be quite organized and structured to keep track of everything when you’re juggling 2 or 3 non-trivial tasks at once, whilst also helping other developers and keeping an ear to the ground for any problem that might come from either the system in the form of logs, or the client in the form of a request or question”, Daniel says.

In the end, time tracking suffered at the expense of being productive and tackling the actual issues at hand (just browsing to Jira to log how much time we used for task X sounds like a simple issue, but it adds overhead both in time and in brain focus). Forget to log for a couple days, and you’ll have a hard time remembering the details in terms of time for each task one week later. This was mitigated a little bit with some other tools such as OneNote or just a plain and simple text file where everything was logged as soon as it happened, so by the end of the day we could have a record for what we accomplished that day. It wasn’t perfect, but we made it work.

As you can see, our mates were very forthcoming with stories of the challenges that they experienced.

Challenges that Bring Discoveries

Diego remembers having difficulties once with a user story that took much longer than estimated. The reason for this was that it was the first story directly affecting two different databases that needed to be synchronized, even though they were so different. It took a lot of his patience and a lot of communication with his colleagues but finally they completed it!

His experience turned into the team planning more detailed about the changes that needed this kind of synchronization, allowing them to work faster and more predictably in these complex tasks.

Daniel, instead, experienced problems regarding the commits: he simply disciplined himself to review the code before committing. This allowed him to step-up his game and produce more quality code that would need less-thorough reviews.

With regards to jira as mentioned above, he didn’t get to implement a solution that worked fully and smoothly, besides trying to log as much as he could on the side and pour it into jira at the end of the day. However, he thinks that a daily mail report to a distribution list from each team member with evidence about the work done would be a great practice that would allow both transparency and accountability for everyone.

But procedures exist for a reason and there might be situations where following a rigorous process could have saved the day. This was the case when following the approval process, according to Daniel. Whenever they had to deploy new code or develop a new feature, following the approval process meant that the team had to be sure that if the code went through, it wasn’t going to have any serious issue that might come back in the future. On big systems such as the one involved in this project, that can make a huge difference on a day to day basis.

Benefits of the Development Process

The dev process we employ here at Making Sense was put into place to bring about a number of benefits. However, it’s interesting to hear from the developers themselves how the process benefited them personally as well as the team and the project.

Daniel felt that the effects of the process provided a sense of discipline and control over the development phases. It actually helped put his mind at rest about the work he had done. He even felt that by learning new practices spelled out by the Making Sense development process, his everyday routine was improved. These benefits also flowed into other areas of his career. Particularly helpful in everyday life was the idea of having defined tasks and ticking them off a list daily.

Likewise, Diego felt the process helped a lot, since it was nice to work with clear rules (always a benefit!). In his case, the team was particularly exhaustive regarding the code review process. New team members love the clarity of the rules because they’re able to trust that people are paying attention to business rules as well as the technical aspects of the project.

As far as team benefits go, both felt a stronger sense of control. This was especially true when, due to unforeseen circumstances, things would go south. Following best practices helped them to keep order and to know what to do next.
—
As we can see, every project is different as well as every member of the team. It is important to adapt our development process to our particular scenario and thus, make our developers contribute with their very best. Thanks to Diego and Daniel for those great insights about our dev process.