I have been fortunate enough to work on a variety of teams and companies in the software industry, each with different methodologies and varying efficiency. Throughout my career as a software developer, I’ve thoroughly enjoyed the problem-solving aspects of working in a development team, and would like to share a couple of the challenges that my former colleagues and I overcame.
One of my earliest was as a junior engineer in a large company on an Agile team. Inadequate infrastructure and un-scalable testing architecture harshly hindered attempts at becoming more Agile. One the team goals was to reduce the defect backlog. The development team would temporarily alter its defect to feature ratio, and the QA team would be loaned some volunteer workers from other teams so it could test more regularly within sprints.
At least a full day of testing by three engineers was required for every sprint as Continuous Integration with automated builds and testing had not yet been set up. Most of the testing was far from being automated and required availability of limited specialized hardware. Even when it was automated, it often meant taking away a specialized device from manual testing inventory.
Consequently, the development and test cycle became longer. Over reliance on manual testing and non-inspection of critical infrastructure initially led to a waste in man power. Several sprints later, these issues were overcome with a harsh review of the goal priorities. Continuous Integration was prioritized and the specialized devices shortage was addressed in the budget. So how can we prevent problems like these arising? By centering efforts on scalable work flows earlier on, and rising above the “good enough for now” mindset. By the time I had left, the company was well on the way to being truly Agile.
In another company as a junior engineer on a much smaller team, I encountered a different set of problems, chiefly poor cross team communication and a high defect rate. One of the reasons for this was because like many time-pressed and under-pressure developers, we took shortcuts in the pursuit of reducing overhead. Features that could take weeks to develop would have no paper trail or accountable visibility of progress until a code review in its final day.
At the time, I convinced myself that these shortcuts were allowable in a small team. I would update my team lead of my progress directly using IM. Relying on long streams of chat history and people’s memory seemed perfectly fine. At the time, I was strongly in favor of over the shoulder code reviews for anything less than 50 lines of code.
It took us a while to swallow our pride and realize that these shortcuts were more likely to cause problems than reduce any meaningful work. I now cringe when I think of issues that will be encountered with that tweaked code that has little to no context in its revision history. The thought of a Jira issue marked as “done” but devoid of any detail except for its brief summary now makes me uneasy.
Traceability of work is important because it is not a case of if one forgets, but a case of when one forgets. Today I am very glad to part of a team that takes these work processes seriously. By having a defined and up to date team process page with checklists for everything from tech debt creation to epic verification steps, developers are much less likely to be tripped up by mistakes from the past.
So how about you? This is a topic on which everyone has something to add. No doubt there are plenty more insights that could be added to this list!
