Multiple Developer-Personality Disorder

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
Stray as architect, current coder and future coder

Stray as architect, current coder and future coder

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.

If your inner architect and your inner coder craftsman are arguing, you’ll know about it – you just might not know that that’s what you know.

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

  1. Architecture and crafting code require different mentalities, and it’s difficult to shift between the two positions.
  2. 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.

My inner architect, coder and future coder fall out a lot

Ring any bells?

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 software solves the user’s problems, and everybody else’s problems should be tackled in the correct domain – often in the toolset or the process rather than the code base.
We had a query on the robotlegs support forum about whether it would be possible to do event -> mediator function mappings in a central location. The motivation was that it would be useful to be able to view these mappings in a single picture, as a description of how the view and application layers interact.

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.

About the Author

I'm an actionscript programmer living and working in a tiny village in the Yorkshire Dales, UK. I used to be a TV reporter, but my inner (and often outer) geek won. I also write stuff. Most recently Head First 2D Geometry.

Visit Stray's Website

Share the post

Delicious It Digg this! Stumble this! Share on Reddit Share on Buzz Share on FriendFeed
  • Anonymous

    It really sounds like you need a vacation :)

    I try not to take coding too seriously. It’s too easy to stress out rules and best practices to the point where you’re not producing any work. I figure as long as I make progress towards the deadline for the day, you (or the future dev) can always refactor later.

    • http://www.xxcoder.net Stray

      A vacation? I think I remember what they were…

      I take everything too seriously – it’s my default position. So, well spotted there.

      Not sure I buy “John Lindquist, casual cowboy coder” though – aren’t you the guy doing the patterns series? ;)

      Refactoring = brilliant. Definitely. But recently I’ve been doing some online support and some coaching with devs under pressure with the schedule to the extent that they don’t see any opportunities to refactor.

      Obviously I dispute this with them – there’s always a benefit in refactoring – but if you can make better decisions at the outset then that’s a win too.

      This really isn’t about rules and best practices at all though. I’m interested in what leads us to make bad decisions. By ‘bad’ decisions I don’t mean that we’d alter based on future learning, but decisions that we know – on some level – are bad, and still go with.

      • Anonymous

        I have been playing the “project manager + architect + current coder” role and the project manager “git r’ done” attitude seems to win out every time. Has the code suffered? Probably. Am I going to lose sleep over it? Nope.

        So, yes, I make “bad code decisions” all the time, but it’s all in the name of getting to the deadline.

        As far as “not having time” to refactor, anything time-related boils down to your management/consulting skills. Nobody gives you time to do anything. You have to make time, push back, or just say “no” (Easier said than done). The argument “we had to write ‘bad code’ to meet the last deadline, we need to refactor before taking on more work” is actually a REALLY strong argument.

        *p.s. – I think I’m getting way off-topic of the original post’s intent.

        • http://www.xxcoder.net Stray

          Not off-topic at all really!

          In a small project you don’t get the opportunity to build up sufficient technical debt that you go under, but in a big project that’s a real possibility. So – it’s not so much about losing sleep about the moral / theoretical transgressions of bad decisions, it’s just that there is a point that can be reached where it’s no longer possible to respond to requests for changes without breaking the existing code base. At that point you’re screwed and so is the client.

          You’re bang on that it’s your job to assess how fast something can be delivered and not accept a deadline / spec that is unachievable. You can’t expect the non-tech folk to have a clear idea about that stuff.

          So – often these decisions get argued as being about git-r-done, but there’s also a point at the beginning of even a pressured and short-lived project where architectural decisions are made – and the consequences of those aren’t as clear cut as “the right way” and “the fast way” by any means.

          If there are several options and you weigh them up and make a best-guess at the right choice that’s fantastic. My experience is that the weighing-up-and-best-guessing process can get skipped or truncated for hybrid-devs. I think that’s a problem and I’m interested in how we can challenge that tendency.