In any software project there are at least five stakeholders in the technical development task:
- The client, who has the vision of the finished features
- The project manager, who has to organise technical resources and timetables
- The architect, who designs the system at a macro level
- The current coder, who implements each individual class and component
- The future coder, who will maintain and enhance the software in the future
On the projects I work on, there’s some overlap of technical roles. Frequently I am – as a minimum – the architect and the current coder, and I’m likely to be the future coder as well.
One of the benefits of merging these roles is that there’s less conflict between the technical roles than there would be if the architect and current coder were different people. Not having to have meetings to explain things saves some time, and at least if you’re likely to be the future coder you can take some short cuts based on the inside knowledge you have of the code base…
…oh, wouldn’t it be great if that were true?
The consequence of merging the roles may well be a reduction in open conflict and time spent in discussion, but this is not a benefit, it’s a handicap.
An absence of argument
In any project there will be tension between what’s right for the architect, who is solving problems at the macro level, and what’s right for the coder craftsman, who is engaged at the micro level. In a multi-person team these differences can be expressed openly. Whether it’s at a formal meeting or just a conversation over lunch, both sides can state their concerns and ideas, and explore the obligations their preferred approaches create for each other.
In a great team these conversations will be welcome, passionate and respectful. In a less cohesive team they might be uncomfortable, and less shared understanding will be achieved, but each side will at least have had the benefit of hearing their own thoughts formed into sentences.
So how does the hybrid developer resolve these tensions between the needs of the architect and the needs of the coder craftsman? My experience is that often we simply don’t resolve them. And yet somehow we carry on building; we make and execute decisions that frequently haven’t even been tested as verbal arguments.
How do you know if you’re suffering from Multiple Developer-Personality Disorder?
Mostly likely, your primary symptom will be cognitive dissonance. A feeling of stress, distraction, mental heaviness or discomfort that results from holding conflicting positions.
More tangibly, these are all symptoms I’ve recognised as being particularly associated with MDPD:
- Expressing architectural thoughts in terms of the specific language constructs that would form the implementation.For example:
- Talking in function names and primitive types instead of higher level objects.
- Code or pseudo-code creeps into ‘Back of a napkin’ system sketches and user stories.
- Bending the architecture to make the architect’s job easier, at the expense of the cleanliness of the code.For example:
- Creating monolithic configuration or controller classes so that ‘everything is in one place, and easier to see’
- Stretching a solution which is intended for one purpose to use it for problems which are less appropriate. This is often called the golden hammer approach “We’ll just use state machines for everything!”
- Forcing the architecture to accommodate poor quality code that was created early in the process and the coder doesn’t want to rewrite.Usually because of one of the following:
- it’s boring
- they spent a long time on it
- it was painful to get working at all
- it isn’t properly covered by tests
Those are my symptoms! Tell me Doctor, just how bad is it?
There are two really big problems that come with being a hybrid developer
- Architecture and crafting code require different mentalities, and it’s difficult to shift between the two positions.
- Your inner architect and coder will impose compromises on each other that they would be too embarrassed to impose on a colleague.
I notice that I tend to favour my inner architect at the expense of my coder craftsman. Maybe this is because I believe architecture is ‘harder’ than simply coding. Opportunities to try things three ways and see which is the best are rarer at the architectural level, and the decisions are more difficult to reverse. As a result I’ve got a lot less experience as an architect, and my architect feels greater pressure to get things ‘right’.
This favouring of my inner architect is especially unfortunate because great architecture enables clean code and then gets out of the way. Even being aware of your project’s architecture when you should be focussing on the internal workings of your class is a sign that the architecture is getting in the way.
Recovering from MDPD
The first step in recovering from MDPD is admitting that you have a problem.
The second step is recognising that the place to resolve that problem is outside of your codebase.
I have a belief that the end user’s problems should be the ones solved by the code. This implies code that is easy to change and easy to maintain – a 1.0 release that is never followed by improvements based on user feedback is a sucky way to make software.
The concept is a great one, but this is a feature that benefits the architect. Instead of breaking the simplicity of the mediator pattern, I feel we should seek to solve this problem from outside of the code base.
We can introduce a tool which finds the mediator-event relationships in the source so that these can be viewed as a descriptive picture. I built a quick prototype and this has actually led to a change in how I write my code – functions that used to be called
somethingHappenedHandler now describe their broad action as well –
onSomethingHappenedClearScreen. This leaves the code cleaner and helps out the future coder too, and the architect’s original problem is dealt with.
If only it was always as simple as sharpening our tools. Unfortunately most of the MDPD problems exist in the domain of thoughts and feelings – conscious and subconscious. Not my field at all – how do you unit-test intent or reluctance anyway? Fortunately I’m married to a rather brilliant psychotherapist (you can read that in any way you like).
So – coming soon is part 2 of this article, in which my partner will offer a deeper analysis of how we can work with our multiple inner-selves, with some practical tips to help you coach the best out of your internal team. If you have any specific examples or questions around these issues leave a comment and she’ll address your query directly.