Most of the time, when reading about architectural design, system infrastructure, continuous deployment, and also testing, it’s all focused on the productive system – the ‘product’ itself. What leaders and architects often neglect, is the importance of tooling for the developers and testers, and the support of the culture. Or at least it’s not part of decisions regarding systems design and and day-to-day organisation.
Of course, programmers like to have the liberty about which tools to use. And I won’t take this away from them. But in many projects I worked in, the environment, technology, configuration and/or setup really gave me a hard time, and just didn’t allow improvements. Also, the productivity also depends a lot in the leadership and the team itself. It’s not just about choosing ‘the right’ people, or doing things like all the others do – but to consider the uniqueness of every team.
From a design/architectural standpoint, these are some examples I had to deal with over the years:
- Not establishing a good architecture. I was working in a big IDE development, in which the different pieces were compiled separately, but there was no versioning concept to manage compatibilities between packages, but not forcing updates of everything all the time. This costed each developer half an hour of time every morning to pull in all the latest builds from build server. And every time you needed an interface or an adaption of a dependency, it was a painful process.
- No concepts and priorities for low level test environments (unit and integration tests). This includes the tools (which already come with most of the languages and frameworks), but also software design that allows usage of mocks and mocked data. I saw teams of platform developers depending on the work of UI package developers, to be able to even test the most basic functionality of their own platform.
- Not staying at the edge of technologies for years. Software is naturally growing in complexity, but most providers of IDE’s and frameworks do a good job to keep technology up to that. But if the management doesn’t want to invest time and money in porting the codebase to new versions, that doesn’t help anyone. Of course trying to always use the very newest stuff can be problematic, but in one project, I was even developing with .NET 2 when .NET 4 was almost released. A developer of a 3rd party software that we included, was even forced to stay on the old technology for years.
But not only from a top-level view, also when looking at the level of a team or a single programmer, there can be big difficulties for stupid reasons.
- Not investing in a basic set of tools. When a programmer says for example he’d be much more productive with ReSharper, just let him have it! Especially when a whole team would like to use it. The time it can save, and the motivation it brings, justify the little investment. Of course it’s not a must have, and many programmers do perfectly fine without it, but I recommend any leader not to make people upset because of such little things! The same goes for diagnostical, deployment and testing tools.
- Not giving working space for innovation. A developer has to stay on top of things! Of course not everyone can be sent to all the congresses and events there are. But at least there must be some company culture about this subject, and the liberty to use some of the working time, to hear/read/watch and discuss the newest technologies. Or an in-house-course for new tech once a while. The company I’m working for now even makes several hack weeks a year, in which people can work on (almost) any idea using new technologies and techniques. And there were quite some innovations coming out of that already!
- Not developing a team culture for work. There are a million ways how to use the coding tools, how to test, how to manage branches and version control, review code, run regression, maintaining a coding style and last but not least how to communicate with each other. A crucial role in this has the team leader, because for a programmer it’s pretty easy to stay behind his screen 98% of the day. There must be meetups, events, perhaps snacks in a coffee kitchen, or at least a fancy slack channel for such things. And the leader must know about what his/her guys are doing all day long, and talk their language. Finally this even has to leave the team circle, and allow exchange with the other teams (or companies) that are involved in the process.
- Loosing the big picture. Like I mentioned before, modern applications are often so complex that it’s impossible for a single user to see the whole picture. But like this, the gap between what the user needs and what he gets quickly becomes huge. And the time to market for a product gets longer and longer. A good leadership and management keeps each team up-to-date with what their purpose is, includes them in the decision process and supports inter-team-communication, from marketing to testing and from accounting to development.
Finally I ended up writing about a lot of things in the same post. But I always try to keep the circle closed – so I’ll try to order my points and put them in a little graphic.
HAPPY PLANTING