Tag: Ethics

They Might be Giants

Don’t let’s start. This is not an article about music from back in the day, but about the elusive “20X” developer who is 20 times as productive as “normal” engineers.

I recently read the recently blogged guide Recruiting Your Next Anakin by “The Sith” Recruiting Training and Retaining Giants (pdf file) whose author (who calls himself “The Saint”) has earned a fair amount of bad buzz on the web. The TLDR is that you should look to hire people with “a calling” who don’t want “balance” in their lives and then work them 80 hours a week to “season” them (i.e. accustom them to working 80-hours a week for less salary than they’re worth). The guide comes out of the video game sector, where there seem to be a number of horror stories of exploitation. It’s a sector which attracts some programmers who have more talent and passion than maturity and who are thus easy prey for exploitation. I’ll leave it to others to criticize the guide in detail – for a sane perspective on recruiting talented engineers, I recommend Joel Spolsky’s approach.

Here I would rather discuss one of the ideas behind the article in question. The article states: “GIANTS can be worth 10X-20X ordinary engineers”. This is not a new idea, and it sounds very “truthy”, but has it really been scrutinized?

When I think of a GIANT who might be worth 20-times the ordinary people in his profession, rather than any software developer, I tend to think of this tall gentleman:

Madison Bumgarner
In software development, while I’ve seen some great engineers, the paradigm does not seem to apply well.

For the sake of argument, though, let’s assume that there’s some objective measure of individual developer productivity and worth in the context of software teams (I doubt it), that it can’t be “gamed”, and let’s assume there are some 20X giants and that there’s way to hire them, and that (as the afirementioned pdf guide seems to assume) 20X giant-ness is an inherent quality of a young developer which can’t be taught to “normals”.

Imagine that you in a team of “normals” and you are then joined by one 20X giant.

Imagine the sprint planning. The first 200 sprint points go to the giant and then everyone else gets 10.

It’s as if your cellar-dwelling adult-league basketball team just got Stephen Curry. You’re no longer playing basketball – on offense you just give the ball to Steph and maybe (if you get past half-court before he’s drained a three) set a pick or box out in the low post. If you play any defense at all, it’s a box-and-Steph.

Imagine the daily stand-up meeting. The part which gets everyone’s attention is when the giant has an obstacle (probably caused by one of the “normals”).

Kind of demoralizing for everyone, but the assumption inherent in the thinking around 20X giants is that developers, once hired, can’t be improved (except by making them work longer hours if they’re willing and able to).

Fortunately, this is a ridiculous fantasy. In reality, with some effort and intelligence, teams and individual developers can improve. And in reality, if someone in your team is accomplishing 20 times as much as anyone else in the team, something is horribly wrong. Maybe the others are busy cleaning up messes left by the “giant” or decrypting unreadable code written by the “giant” at 3 a.m. when the effects of the energy drinks have worn off.

The software craftsmanship movement embraces the idea that not all developers are at the same level, but part of a software craftsperson’s job is to help the rest of their team to improve. We value the quality of our work as much as the quantity, because software is never really done, and going too fast now will force us to go much slower later. We strive not to be giants among Liliputians but highly competent professionals on teams of profesionals and in a larger community of professionals.


With software craftsmanship there’s a lot to say about tools and methodologies, but if I had to sum up in only 1 word what you need to do to be a software craftsman or craftswoman it would be “care”.

As in:

  • care about the people (including your memory-challenged future self) who will have to work with the code you’re writing today – 6 months, 2 years or maybe even 10 years from now
  • care about the people who will be using the software you’re developing today
  • care about the people who have staked their reputation on the product you’re developing today (and about whatever promises you make to them)
  • care about learning to be better at what you do
  • care about what your fellow team members are working on and about being able to give them a hand if necessary
  • care about mentoring your fellow team members and others

Some cynical people think that Software Craftsmanship is a fad to sell training and consulting. There may or may not be a grain of truth to that, but there’s no certificate for caring – either you care, and the results will gradually become evident, or you don’t care, and the results of that will also be evident at some point to somebody. If you do care, there are many free resources, including this blog, which can help you learn about the methodologies and tools you need to become a software craftsman or craftswoman.



Uncle Bob’s Oath Proposal

Robert C. Martin recently proposed an oath for the software professional. I applaud Uncle Bob’s efforts to encourage higher standards of professionalism, which have inspired me personally, but his oath is based on premises which seem unrealistic to me. The oath has already received much intelligent criticism, from Ron Jeffries, for example. Uncle Bob seems to want us to have a “priesthood” aspect to our profession, but it’s based on questionable analogies.

We are not like doctors and lawyers, who receive quasi-governmental powers in exchange for a difficult certification process, a code of conduct and possibly governmental or quasi-governmental oversight (which, by the way, does not always eliminate abuses of the aforementioned powers and sometimes serves to cover them up). We are not like academics, either, where a “priesthood” is necessary to protect people who invest time and resources into a career path which in many cases has limited commercial value (For example, how many of us would pay big bucks to hire someone to read Sanskrit or analyze Tolstoy or survey the spectral emissions of a distant galaxy?).

Clearly, we have some important issues to address in software development, including:

  • technical debt
  • ethical implications of the products we develop (the potential for fraud or invasion of privacy, for example)
  • risk of project failure
  • handling and security of sensitive data
  • the rapid and continuous proliferation of new tools and approaches (and the need for training/education that this creates)
  • diversity issues (notably gender, race, and age)
  • repetitive strain injuries

Uncle Bob’s oath attempts to address a few of these issues, putting much of the responsibility on the individual developer, who is assumed to receive in exchange for this responsibility the additional autonomy and the time to do his or her job as he or she sees fit. That sounds nice, but software development is often a collaborative team effort, often serving a goal which is not chosen by the developers themselves, so responsibility should be shared.

I think a lot of companies could gain a competitive advantage by treating programmers as respected, autonomous professionals and to provide them with training or time to self-train (and some of them actually do it). However, I can’t support an oath which assumes that all employers do that to the extent assumed by Uncle Bob.

Here’s my humble (rough draft) revision (my additions in italic) of Uncle Bob’s oath, with commentary in blue:

I Promise that, to the best of my ability and judgement:

  1. I will not produce harmful code which is intended to defraud or to harm innocent victims.(Uncle Bob’s version would eliminate from the profession anyone programming weapons systems, for example. My version is more permissive but still covers cases like Volkswagen and Bernie Madoff )
  2. The code that I produce will always be my best work. I will not knowingly release code that is defective either in behavior or structure. conceal defects in the code’s behavior or structure from my employer or customer.(Living with defective software is what made certain software companies what they are today. Far be it from me to say they made the wrong choice, but an ethical developer will be transparent about this choice. Many developers have loyalty clauses in their contracts which would prevent them from announcing a defect publicly, but it’s always possible to inform the product owner.)
  3. I will produce, with each release, a quick, sure, and repeatable proof use the most appropriate techniques available to me, taking into account my employer’s or customer’s wishes, to ensure in repeatable fashion that every element of the code I produce or modify works as it should.(I think the employer/customer wishes and business needs can not be ignored just because there’s a “right way” to engineer, and a developer can’t take responsibility for the entire base of legacy code for a short-term add-on project.)
  4. I will make frequent, small, releases so that I do not impede the progress of others. There is no number 4. (This is micro-management by oath. If a company has a 6-month release cycle, I can encourage them to do 2-week sprints, but it’s not always my call, and they might not be ready to handle it.)
  5. I will fearlessly and relentlessly improve the code I work on at every opportunity. I will never make the code worse without a commitment to correct the worsening by an agreed-upon date.(This one is not bad, if you interpret it such that “every opportunity” gives some leeway to respect the wishes of an an employer who discourages certain code improvements. I added a fail-safe for cases where a short-term need requires a quick hack to be repaired later. I also added a specifier so that I’m not responsible for all the code in the world but only the code I touch. I removed the notion of fearlessness because I know of code that only a fool would change without fear.)
  6. I will do all that I can to keep the productivity of myself, and others, as high as possible. I will do nothing that decreases that productivity.(The first sentence is enough. The second is too inflexible.)
  7. I will continuously ensure share information to facilitate that others can cover for me, and be open to receiving information to facilitate that I can cover for them.(Staffing and how to cover for an employee’s absence are management’s call – a professional who is not a fully independent contractor should facilitate management in this effort but should not have responsibility for it. )
  8. I will produce estimates that are as honest as possible both in magnitude and precision. I will not make promises without certainty transparency about uncertainty.(Honesty and transparency are important for estimates, but no one can eliminate all uncertainty. Some slack should also be built into estimates to account for uncertainty and interruptions and tasks not directly related to the development itself.)
  9. I will never stop continue to learning and improveing my craft.(Let’s not judge the developer who chooses to attend their child’s piano recital instead of going to a coding dojo or a user’s group meeting. We have a long-term commitment to improve, subject to short-term interruptions.)
  10. I will keep informed about security issues and follow important security guidelines as appropriate in order to ensure the security of sensitive data.(This is my own addition. It could be covered under #2 and #9)
  11. I will not knowingly post a complete solution to what is obviously a computer science homework problem on StackOverflow or other public forums.(A recent pet peeve of mine. It’s good to help people learn, but helping someone cheat while spoiling a good homework question for posterity seems like a breach of ethics.)