What would happen if you would let the developers figure out stuff, rather than assign them roles, give them processes and treat them like they’re machines?
I’m not saying ‘do it’, but I am certainly saying ‘think about it’.
“I give you spec, you give me code, yaaa?” – that’s not how to get the best results.
While researching for this blog post, I discovered that I am (of course) not the first person to have this thought. Searching for “Developer Driven Development” leads me to this post where the author suggests to throw out TDD/BDD and replace it with “DDD”, meaning let the developer do whatever they want, trusting that they will write good code.
I wouldn’t go that far, but some of it makes sense.
No, we cannot throw our development methodologies out – for two important reasons, that each in their own right would be enough:
-
Code should be testable regardless of whether the developers think they write perfect code that doesn’t need to be tested. Even if they somehow do write code with no errors, making sure code is testable has other benefits than just ensuring it works. That’s a topic for another day.
-
It’s important for maintainability that code is written in more or less the same manner throughout the company, regardless of which developer that writes it. It ensures other developers can more easily maintain the code.
However …
(this is where I get to the point)
There doesn’t need to be a process for everything. Some guidelines are needed, but if you have a team of highly intelligent people, why not trust their intelligence to make intelligent decisions?
But it means relinquishing control.
In many companies, prioritization of tasks is done by the ‘business’ and certainly not by each individual developer. If a developer wants to do that thing which they know is great for the product but doesn’t really carry any direct value, they have to do it in their spare time or do it in between tasks when no one is looking.
I did that. Years ago, I wrote a search page for our logging table and it’s been saving the team countless hours. Had I put it on some task list to be prioritized, it would have been prioritized to the bottom of the pile.
Not for pet projects
I’d like to propose that a certain percentage of the time, it should be up to the developer to decide what they want to work on. An intelligent person will already have a multitude of ideas that they never had time to implement.
You may think this sounds an awful lot like Google’s 20-percent concept, where they essentially allow people to spend 20 percent of their time on pet projects. No, that’s not what I’m proposing. Letting each individual introduce new products and major features on their own initiative, is definitely outside the scope of what I’m suggesting.
If you let an engineer design a remote control then … well, most remote controls ARE probably designed by engineers, so you know what will happen, just look at your current remote control – if it’s like most others, it probably has a 100 buttons that the engineer thought was useful, whereof most people just use 4 to change channels and adjust the volume.
Pay your debt
What I am suggesting, is that you set aside a certain amount of time (perhaps a third of the time) for ‘other stuff’ where each developer can work on whatever they feel needs to be done, but would never be prioritized by the ‘business’. It could be spent on a refactoring session, optimization of database indexes, maybe a nice GUI improvement or fixing a bug.
Some people like to refer to this work as ‘paying your development debt’ because the need usually arises as a result of hurried development that needs to be finished up nicely after the deadline has been reached.
Let me tell you why I suggest to “waste” a lot of time on this ‘other stuff’, whatever it is. It’s because it’s not wasted! Not if you have intelligent people making intelligent decisions. A decision can be great, even if it doesn’t directly increase profit or is part of the corporate strategy.
To sum up: Trust intelligent people to make intelligent decisions.
No comments yet.