Month: March 2016

The 1/10x developer

The 10x developer is a common myth. That there are developers out there that are 10x as productive as a “normal” developer. Some people believe in them and some don’t, but probably YMMV when you define “normal”.

For me, I’m a believer in the opposite the 1/10 developer because I am one! I’m doing a bit of work looking at other programming languages. But since I don’t grasp the slightest thing about how they work and they are both from an open-source background, there are a million ways to skin each cat. That means that I need to spend 3-30 minutes on Google for each line I write. An expert in these languages would easily be going 10x my speed.

That’s the problem when you start using a new “high productivity” language.

We know that Fowler is years ahead, you cannot measure productivity. (2003! Damn you, Fowler)

I agree of course the LoC is a poor metric of productivity. Especially if you compare R code with Fortran doing the same thing. Everything is solved with one more level of abstraction, amirite? But also within C#. I’ve done code analysis, even within the company, that shows some people write exceptionally dense, highly abstract code. It takes a while to adjust to the “new normal” when you start reading their code, but the metrics showed something like 2x IL instructions per line of compiled c#.

Maybe if you are working on the same project, the number of completed stories tells you something? Maybe not. The point about the best developers working on the hardest parts of the system is well made, but we often don’t call those people developers, we sometimes call them architects. People who imagine the whole problem, encapsulate it, pick a technology, code a spike, check it in, drop mic, walk offstage. They don’t complete hardly any stories (only fake ones created to pad the sprint!).

I think that architects (if you believe in them) are also not that productive. They turn up before the project has really started, they don’t know that much about the problem in depth, but they’ve seen a lot of other projects at this stage and hopefully they make some choices that enable to you build without having to tear a lot of chunks down. When the project is in the high productivity phase when work is flying out the door, the architect has drifted off onto something else and when they do turn up it’s a pain.

So, I read that when people built cathedrals before there were principles of structural engineering and architects, people would just try building stuff and see how it went. If it started leaning when they got up high then they took that bit down and tried again with a bit more buttress. Sometimes that worked and sometimes it didn’t. That’s why building a cathedral sometimes took more than a century. Requirements change, but massive inefficiency exists, whether we can measure it or not.

So, the other thing is that ALL skills are exponentially harder/rarer near the top. Pretty much any fully-able bodied person can complete a 5 hour marathon, some can do a 4 hour, some who are at a time in their lives to commit a lot of time to training and with the physique to survive the training can do under 3. However, getting from 3 to 2:30 requires a superhuman. Getting from 2:30 to 2:09 takes half a life of dedication, suitable genetics, youth nurturing, etc. You want someone who can write you a web page, plenty of those (no offence, web devs). You want someone who can write you a full stack fintech disruptor, somewhat rarer. You want someone who can imagine, design and code bitcoin? One in a century*. I’d recommend “programmers at work” for some stories of transcendental amazingness. OK, a lot of the stories are about the point where programming came out of the research lab and became a job, so it was the wild west. And those people are notable because they actually made stuff that worked at all, and actually sold. The standard for “average” and “miracle” have changed, but the gap is still there I think.

So, even without a real measureable metric, I know that I’m 1/10 of a normal dev in what I’m doing. Even non-specific measures like “architecture quality as judged by a community of your peers” or whatever, I’m doing a bad job at coding.

Back to the 1/10: Even though I’m running slow, I’d say that I’m one of those people that’s still useful, even though I’m inexpert at almost everything! I heard the expression recently a “T-shaped” employee. I think that I don’t have a skill that I’m particularly deep at. Possibly criticising others? That’s more of a hobby! Possibly I’ve spent more time thinking about the SDLC, rather than JavaScript libraries. Maybe that’s my thing. Anyway, so that’s the point, when I’m running at 0.1x I’m doing a bad job at coding, but I’m not coding, I’m learning. I’m also pretty slow at learning, but let’s say I’m learning whether we should let the real developers at this thing, and what the impact on the SDLC will be.

 

* Actually, that’s a lie. I don’t believe those ultra-hard problems are solo efforts, but get so many rare talents to cooperate, even for a few months is hard, I believe. That’s probably one of the major changes since the 80s. Now it is simply not possible to write a world changing app by yourself. No one person could have written iOS or SQL server or Linux. Yes, the core of a few languages was written by one person (e.g., Ruby) but what makes them fly is the adoption of the frameworks (Ruby on Rails, etc.).

Deadlines are dead

One of the things that blows my mind most about software is the deadline. The problem is that often what you are trying to do when you start isn’t what you end up doing. Sometimes that is even on purpose. Software is soft and when it starts working, our minds expand and so does the project. Of course, it isn’t all good news; sometimes things might look simple for simple cases and just be impossible for everything else. Sometimes close enough, just isn’t good enough; when that happens, deadlines go out the window.

The question is, how do you say how long it will take you to do something when you don’t know what you are going to do? Maybe that isn’t the important question, maybe the deadline is more important. Maybe the real question is when do you need it by?

For me, there are some further questions, most of them come down to why do you need it by then? There might be answers like this:

  • If we don’t have a system that is reporting our errors and complies with the MPASS15 legislation by midnight on the 13th March 2016 then we will be fined 10 million dollars.
  • We need to have clients able to access our movies on their iPhones by the end of the year, or we will see people move to other networks

The first is a “hard” deadline with a very tangible and measureable cost for failure at an absolutely fixed date. Quite often this type of deadline would be associated with a legal change. The second type is a much vaguer proposition. In terms of the project mission statement, the second example is not good, far too vague. However, it might be the case that it is much more important that the software is brilliant. In the “legal” example, we might get by with a bare bones system that complies but does no better. If we do that for our clients, that might not be good enough and they might leave anyway.

I’ve started looking at it in this way: Delighted Vs. Disappointed and that means:

  • What would the date be to make you surprised and delighted that the project was done? What would early completion allow you to do? It has to be better than “because I want it done by then”; tell me something like “that means we will be able to include the results in the next quarterly report”
  • What would the date be to make you disappointed? What are you going to have to change if the work isn’t done? What real risks are you now exposed that should have been removed? Are we going to have a lost opportunity cost? Or real financial costs like maintaining an old system?

Of course, delighted and disappointed expands into all areas, not just the timeframe and helps us to set limits and expectations.

In many cases, we can make a “best guess” about a project that will be 80% accurate, 80% of the time and that is important as probably, our project is just a piece in a bigger puzzle. Doing the sums on those puzzles is the higher mathematics of management, and estimated project data is often all we have.

But, to allow your stakeholders to get confidence in you, you have to understand their motivations and that means asking why.

[Originally published in 2012]

Code

So, what is code? If you are reading this you probably already know. But you probably also know people that think they know

But actually, what they are really wondering is why they can do a formula in excel and why everything takes a long time.

Perhaps you could get them to read this: http://www.bloomberg.com/graphics/2015-paul-ford-what-is-code/

It’s a pretty wide tour, covering some of computer science, the culture of programmers, corporate politics and even git. It actually knows all the stereotypical answers and references them, but it’s too long for anyone who doesn’t have some skin in the game. For instance, I’m not going to show this to any of my family who don’t code in the hope they will understand me better. The fact that it’s a 30,000 word article tells them enough; and they already know: that I’m tedious.

However, it’s pretty good; I quote: “You’ve learned that the only appropriate reward for people who write JavaScript is more JavaScript.”

Thoughtworks Technology Radar

I’ve probably mentioned this before but the Thoughtworks technology radar is worth a look. You don’t have to agree with their conclusions. Radar just shows you what to be aware of, you don’t have to shoot. However points of note:

  • Nancy is now “the default choice on our .NET projects” (over ASP MVC?)
  • Comments on Ember.js are interesting, not only for the side-swipe on Angular:
    • “Widespread usage of AngularJS continues on ThoughtWorks projects, although not every experience is positive. We continue to advise teams to assess whether the additional complexity of a single-page JavaScript application is necessary to meet their requirements. We also recommend assessing alternative frameworks, and in this radar edition we highlight Ember.js which is growing in popularity within ThoughtWorks. Ember is praised for its approach of opinionated convention over configuration, responsive core team of committers, performance, and build tooling support via Ember CLI.”
  • Containerisation of course gets a big say, plenty of comments around Docker and the supporting ecosystem of tools, but here’s the skinny: it’s not about going to Docker, it’s about moving away from app servers:
    • “Easier automation, easier deployment and a reduction in the amount of infrastructure you have to manage lead us to recommend embedded servers over application servers for future projects.”
  • QA in production: where else? Actually this is more about the kind of DevOps monitoring and support done by programmers, rather than having a lot of manual “then run the cash check report” kind of process that dominates a lot of business operations jobs
  • Decoupling deployment from release: using feature switches and the excellently named “dark launches”. I’ve seen a lot of these things in use, but recognising them as a pattern can help. Deploying to production a few hours before you go live is not a recipe for deep and restful sleep the night before.
  • One of my favourites: Products over projects. The project has an end date when it is done, a product exists for the lifespan of its use.

There is an additional side article (called “Implications of tech stack complexity for executives“) which doesn’t really apply for people working in teams that are attached to a business unit. We are used to having a few multiskilled developers rather than technology-layer silos (is that a silo? Seems like a layer is sideways and a silo is vertical…) but this diagram sums up the article:

My 2 cents on that

  1. It really isn’t that bad is it? Surely no one except for your FANG companies are doing this. There are separate pieces on “web scale envy” and “microservices envy“
    1. I can imagine a front end that has been clapped onto a whole company’s output, or a system that has proceeded by acquiring other companies. I cannot see how this would happen otherwise
  2. Where are your integration points to other applications? This still looks like one application
    1. This is definitely one route to end up with Oracle and SQL and … because each application you buy comes with another stack.
  3. Where are the users?!

Anyway, tech diversity is a fair comment. Personally I’m somewhat in favour of a bit of polyglotism. If you don’t start bringing in the new tech, you will be turning to stone and you won’t be able to attract the new talent. If you do introduce it and don’t understand it then you are going to be in a mess. If you try and introduce it into very small teams (either by technology layer, or by SDLC cycle) then you will have problems, the tech is just too diverse to be an expert at all of it.

We’ve often said that our unified MS only tech stack is a strength, this article says that is not the future.