Friday, 20 March 2015

Just One

I was eyeing up the current (and forthcoming) mac laptops the other day, as you do. I was struck by the "one port" fascination. I've yet to buy anything that uses thunderbolt, so the USB-C thing makes no difference to me. But I am struck that that having one port isn't a major leap forward - it just offloads the demultiplexing problem somewhere else.
For instance, as I sit here at my desk my laptop has 5 wires coming out of it: power, ethernet (wireless in my office is variable), backup disk (happens to be old enough for firewire but can use USB), pictures to the monitor and USB to the monitor. Before I wrote this I copied a file to a USB memory stick, in case things aren't as expected where I'm going later. The monitor's USB ports are full too: audio interface, keyboard, mouse and fitbit dongle. I also often plug in a cable to access a phone; my laptop connects to a projector on average once a week.
At home there's a similar story: I've got a backup disk (spot the ex-sysadmin who found time machine over wireless unreliable), an external disk of pictures and music (editing photos is just faster on a wire than a wireless network), an ipod, a camera (memory card or USB), occasional connection to the TV for family streaming, occasional USB stick and power. And with no external screen to act as a hub and moving between rooms with the computer no fixed place for a separate box to demultiplex whichever combination of stuff I'm using.
So, if I got a new laptop, could I make one port work? Probably. Though it would involve spending money on new adapters, maybe hardware and some rechargeable batteries for wireless stuff just to get the current, or equivalent, gadgets connected. Would I gain anything? Not as far as I can see. I'd still have boxes and wires, just slightly rearranged. I don't recall ever thinking "I wish I had fewer sockets on my computer".

Which gets me to the software analogy. Message busses are all very well. I've written and used more than one. But if they're the only way of communicating in the whole system, they bring their own challenges.
Scalability for one.
Fit to function for another. I don't mind having a separate channel for audit logs, or system management. If the bus breaks or load goes up I still want these important functions, without creating headaches for security, priority and API clarity.
Does doing all communications (or persistence) in one way buy me anything? I like reuse and patterns as much as the next OO-person. There are limits to how much complexity I want to put up with and a common approach can reduce both local and system complexity by sharing the overhead. But, increasing system complexity needs this payoff. Some connections are special, some adapters are too expensive.
A fundamental point I make when training people to solve problems is that there are many ways to solve even quite simple problems. Some may be better than others, but the concept of a solution space, where each solution has its own properties, is an important one. If you vary the parameters of the problem you vary the point in the solution space that is the best fit. There may be a solution that is a pretty good fit to many problems, but far from ideal for some cases. Shading the whole of this space with the biggest crayon you can find isn't big or clever.

Friday, 6 March 2015

Continuous Deployment and Programmers on Call

Two days ago I was attending an interesting Brighton Java talk on continuous deployment by Jose Baena followed by a discussion led by James Stanier. I heard about some new tools; got reassurance that what I was doing was also, roughly, someone else's approach; and that the tricky problems were felt by others too.
One of the discussion points was "Should developers always be on-call for their code?". My gut reaction was "always? No! I've done that - 18 months with a pager - no way, it's soul sapping." In the shower this morning I arrived at a more nuanced answer, that (of course) agrees with my gut reaction. The reasons are intertwined, bear with me while I pull them apart a bit...
First, there's some basic pragmatism: What do you do with the code written by someone that left? If you pair program, who's on call - both of you, take it in turns? If I've maintained a method in a class do I suddenly get the entire class?
Second, and leading from that thought, is the issue of who dials the number of the right person? If an organisation gets beyond about 6 people (arguably 2 if you work in layers of a stack) there will be failures where it isn't immediately apparent who owns it. Now you need 1st and 2nd line support. By the time first line has isolated that it is a particular unit which is at fault, not the database or the user interface it connects to, then they are probably in a position to make the fix faster than they can get the 2nd line on the job.
James offered the thought (bait?) on the night that being on call might prompt a sense of responsibility. The come back from the floor (not me) on that was that developers paid for call outs wouldn't be motivated to produce good code. Getting called becomes a source of income. My experience is that after a while, with a decent wage, the intrusion on my life mattered more than the double time. However, to some extent I think he is right - throwing code over a wall to be someone else's problem isn't how I like to work. Even in the 1990s I mixed development, test and support. However, it does lead me to my third point: given the first two issues, it is clear that matching an individual to a block of code is problematic. Many problems require that the on-call person has the sophistication to move up and down the stack, look at systems issues, understand the relationships between the parts. So, maybe the on-call needs to be at a team level. There's still a responsibility. But there's also the responsibility to your team mates' social life, not to mention being fingered for code which was hard to understand and fix!
And there's the fourth point: Yes, feel responsibility for your code. This isn't ownership* though. As a team the power to fix the code needs to be dynamically allocated.
So, being on call - as a team, but on rotation - motivates responsibility and quality. It gives a reason for good testing, code reviews, not sitting in a corner but getting the whole team's work, and seeing the full development cycle that putting development and ops together implies.

* I don't mean avoiding "ownership" in the sense of "I'm going to own this problem", but in the sense of "this code is my precious, it's mine!" or "I'm leaving the company and taking it with me".