The process of developing software involves a lot of creativity from the developer. Some would even say that the software that can be developed is only limited by the creativity of the developer. Whether you agree with this is not important, what you need to realize is that developers are often creative people (in their own way).
The more creativity a process requires, the harder it will object against any form of restrictions. The same goes for people, a very creative person will feel best when he can use his creativity to the fullest. An individual can never have complete freedom in a corporate environment:
- The company needs to be profitable
- A company involves many individuals that need to work together
- Pressure on the individuals to come with results
What are these obstacles translated for software development:
- Developers need to implement features
- Created code has to be maintainable by the rest of the team
- Strict deadlines
- A complete technical report of how things needs to be implement is given to developers
Each of these obstacles have their own consequences.
Forcing developers to spend all their time on implementing new features, and not giving enough time to write tests or do refactoring will lead up to code that is hard to maintain and contains a lot of bugs. This is ironic because after a while the team will be spending most of their time fixing bugs, leaving almost no time for new features.
To keep code readable for other individuals a set of code conventions is agreed upon. There are no significant downsides to this as it is only restricts the developer at the level of the format and not the code itself. However for truly maintainable code, the code should be self-explaining and documented. This is often harder to realize, not necessarily because the developers don’t want to (most will realize the value of this) but because it is hard to determine if code is self-explaining and well documented, after all you have just written it and it is completely clear to you at this moment. To deal with this a code review is required where the reviewer decides if it is good enough. This requires an open mind of the developer whose code is being reviewed, as remarks will be given.
Strict deadlines have been a killer in the software industry since the beginning. With the rise of agile development the impact of a strict deadline has been reduced. But as mentioned in … TODO, the entire company as a whole needs to be aware of this. Asking for a fixed scope, time and quality project can only work if the work can be estimated perfectly, which is never the case. Deadlines are not bad, but only if the scope of what has to be delivered is not fixed. If the agile methodology was enforced correctly the most valuable parts will have been implement and be functional.
Depending on the team organization and the used methodology it is possible that the developer gets a request to implement something that has been worked out for them. Such a request that explains the technical details is a bad idea as it takes away the most essential freedom from a developer. It reduces the developer from a creative individual to a working monkey that doesn’t have to think, just do.
Giving the developer (as a team) more freedom will result in better software with more ownership. Let them be responsible for the quality and determining when a user story is done. I can’t imagine any developer being happy when they have to perform a lot of bug fixes on code they created.
There will always be tension between management, eager to see new features, and the development team, craving for freedom. This tension will keep both parties ‘awake’ and will result in the most optimal workflow. The biggest mistake to make would be to give either party too much power.
If management has too much control, features will be released containing a lot of bugs. The development team will be upset and become angry because they told you that the feature was just not ready yet. The management will become angry as the development teams seems incompetent to create a decent feature without bugs.
If the development team has too much control, features will often be re-designed to make the most optimal solution, and the team may start experiment. This leads to a long release time for new features, making the company less competitive, forcing management to take action resulting in the first situation.
It is clear that a good balance has to be found between the two. Management should realize that developing new features is a time-consuming task if done right and taking shortcuts will cost more in the long term. The development team needs to realize that it is essential to release new features and that no code is written just for the sake of writing code. Both parties eventually want the same thing: to release new features that are of good quality as soon as possible.