The Developer’s Dilemma
I often see developers, team leads, development managers and so on who say they don’t have time for non-programming activities. Because of an aggressive schedule (I don’t know any company that doesn’t have an aggressive software development schedule), there is no time for:
- Documentation
- Recruiting
- Blogging
- Experimenting with new frameworks and tools
- Building experimental features
- Looking into new processes
- Doing security audits
- Fixing security issues that nobody knows about
- the list goes on…
All these things though are crucial in the long term to ensure the success of the project and the company. Many recognize that and often the complaint is: “my boss (who may be a lead, a manager, director, VP Engineering or CEO even) doesn’t give me the time and flexibility I need”.
My theory and of course it’s just my own and I very well may be mistaken, is that when given the choice between improving code/fixing a bug and doing something else (non-programming), the developer or manager will always choose improving code/fixing bugs. No matter who I am in the chain of command, programmer to CEO, what I like the most is improving the product.
I think a good place to start is tech debt. We all have a bunch of it and most of us have devised a method to at least keep it from growing: commit to at least a couple tech debt tickets every sprint. It takes discipline but it doesn’t throw the schedule because once it is done consistently, it’s burned into the velocity an the project has a predictable timeline.
Experimenting, documenting, and so on can also be done as long as the developer/manager has the discipline to commit and block some time consistently. It doesn’t have to be a lot of time, but it has to be consistent. That time can be used on recruiting, blogging or else depending on the situation… and soon it becomes a permanent part of the sprint and I strongly believe it’s the only way a team can innovate and that’s key to the company’s success.
Of course this only addresses the time problem. There are other barriers to experimentation in many businesses. Some technologies, frameworks, processes simply can’t be experimented with until some other changes happen in the business.