Month: April 2016

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.

Advertisements

TDD is our friend, but…

“Animals are our friends!!”, comedian Bob Goldthwait used to shout, adding “But they won’t lend you money.”

One famous definition of legacy code (from Michael Feathers) is “code without tests”. I would extend that definition to say that it’s code which does not have tests for the behavior you want to have. TDD will get you code that is well-tested for the behavior you want when you develop it. If your code does anything innovative, some of the behavior you want will almost certainly change over time.

So TDD is our friend, but it won’t eliminate all legacy code. What it will do is make it easier to know when we accidentally change behavior. It doesn’t necessarily make it easy to change our code’s behavior, either, but it gives us confidence to tackle the change because we know that tests will catch and allow us to fix any little mis-steps before they become more difficult and time-consuming to find and fix, and, importantly, it nudges us constantly to design our code in a way which allows it to be refactored with less trouble and risk.

Quick thoughts about Seth Godin’s article “Our Software must get better”

I’m a long-time Seth Godin fan, so I read with interest his recent article about software quality.

With the examples he gives of inadequacy in software – iTunes user experience, the Macintosh’s built-in address book’s slowness and difficulty with importing and exporting data, and general unreliability and lack of Macintosh-compatibility of stamps.com – he’s focused mostly on the user experience aspects of software, which I think misses a key point. I think the biggest problems for software users these days are not slowness, confusion, frustration and extra clicks – though these can be real problems. The big issue for software users today, IMHO, is in the realm of data security, transparency and privacy.

Software in general is getting really good at collecting data profiles of the people who use it. I think this can be done in an ethical, transparent and generally secure way which generates value for the software’s creator in a fair and honest exchange for the user experience that consumers want. Is that what’s happening now? Not enough to satisfy European governments, who are taking action on this issue.

Seth Godin is smart enough and experienced enough to set up a kickstarter for a better Mac address book that is fast and can handle imports. But he would like software users to take ownership of the quality of the software that they use, by explicitly paying for what they use and by insisting on a user experience that meets their needs. On a large scale, that would be a pretty radical change, which would surely have a positive impact.

For the moment, most users either don’t know what “better” is or don’t care enough to pay for it. The trend among the giants of the software industry landscape seems to be that better means “smarter”, which means “knows what you want”, which is a problem in the aforementioned realm of data security, transparency and privacy. If you collect personal information, you must protect it forever and use it in a way which is ethical and transparent. If your smart assistant in the cloud knows that you have an appointment next Tuesday with Doctor So-and-so and the Such-and-such Clinic, who else will know that? The only data which is 100% guaranteed to be private is data which is never collected.

Ironically, the respect for privacy seems to be better in free software (Mozilla, Linux, etc.) than in software which people pay for. Godin alludes to this in his point “C” as to why software is mediocre.

Seth Godin would obviously like us, the software craftspeople of the world, to insist on better user experience, and, ideally, he’s right. It should be part of the software craftsperson’s ethics to improve the user experience. It’s not always clear, though, who should be responsible for defining what constitutes improvement or deciding what time and resources should be allocated for it.

At a minimum, we as developers can strive to create software which is easy enough to change that the user experience can be improved easily once we understand what improvements need to be made. We can also strive to treat the users’ personal data as a precious commodity to be protected, we can sanitize our inputs, and we can use the best encryption techniques available for passwords and other sensitive data.

NIO2 is great… until…

In Java 7, Oracle gave us a shiny new API to do dingy old file-related tasks with less boilerplate code (and with shiny new functionalities like file change listeners, memory mapping, asynchronous I/O, etc.), and in Java 8 Oracle extended the API to use Streams.

I recently discovered that it’s great… until you need to delete a directory on Windows. The odd thing is that I really wasn’t using much NIO code.

I have integration tests where the code under test creates a temporary directory (not using NIO). The code under test test writes a file into that directory (not using NIO). The test used NIO (Files.lines()) to read the generated file and a static file for comparison. The post-test clean-up deletes the contents of the temporary directory and then the temporary directory itself (not using NIO).

Without using NIO to do the deletion, I had only a boolean (the result of File.delete()) to tell me that the directory was not actually deleted. Switching to NIO (Files.delete(), which throws an exception when it fails), I could see that the deletion failed because the directory was supposedly not empty. This might be caused by the never-to-be fixed bug 4715154 in the JDK.

I tried looping with delays and forced garbage collection (as suggested in this StackOverflow comment), but to no avail. When I got rid of NIO in the test code that reads the files for comparison, then the deletion worked. All’s well that ends well, I suppose, and the hour spent debugging that issue was educational.

I thought it was worth writing up a warning about this, though, because when you’re doing TDD you don’t expect to spend an hour debugging code in your @AfterClass method which does nothing but delete a directory and its contents.

 

 

Finding Fun

It’s hard to master software development if you don’t enjoy doing it, so you’ve got to find fun. There’s a lot of fun to be found in software development (unless you’re one of those people who really can’t program).

We should be thankful that our job allows us to have fun. There are plenty of jobs where it’s a lot more difficult to find fun.

So how to find fun?

Learn

Discovery and mastery are fun. If what you discover and master are relevant to your work, your employer will probably accept that at least a small part of your time is spent on learning. It’s in your employer’s interest to have developers who are up to speed. At a minimum you should be able to organize a “brown bag” session to learn during lunch time.

Share learning

Brown bag lunches are also a fun opportunity to share what you’ve learned with others. So is pair programming.

Gamify

Challenging yourself makes things more fun. Challenging others adds even more fun.

Doing TDD lets you create little challenges all the time for yourself. You can also challenge yourself to move the needle on certain code metrics (test coverage, cyclomatic complexity, PMD/Findbugs issue count, etc.), within reason (choose metrics which actually add value to your work). Following the Boy Scout Rule, you can challenge yourself to make a big ugly method into small, beautiful methods.

One suggestion I heard recently to make pair programming more fun is to play “TDD pong”. One member of the pair writes a test and then challenges the other to make the test pass. Then the roles switch.

I also heard recently from a scrum master who invented a role-playing system (using Star Wars characters to bridge the gap between older and younger developers) where each developer is assigned for a sprint a certain character.  Each character gets points for doing a different thing, such as writing “perfect” unit tests, facilitating communication between developers, enhancing code performance, etc.  Whoever has the most points at the end of the sprint gets a small prize. The idea is to get less experienced developers  to adapt good practices by having them focus on one practice at a time.

Take micro-breaks

When it’s not fun, stop for a minute. Even when it is fun, stop for a minute now and then. Your eyes and wrists will thank you, and things will stay fun longer.

Laugh

We can laugh at what we do, our processes, our teams, our way of thinking.

We live in a silly world. A generation ago, if you walked down the street alone while having a conversation, people would think you have some form of schizophrenia. Now they just think you have some form of bluetooth device. It’s best not to take things too seriously.

Laughing at your test data:
Be careful, because some of your test data might turn up in a commercial presentation which could make or break your employer’s reputation, and you don’t want to waste too much time on non-essential tasks, but you can make your test data more fun.

For example, if you have a test database which needs a list of video game titles, you could enter “game1”, “game2”, “game3”, etc.  Or you could enter “Accountant’s Creed”, “Angry Nerds”, “Bassoon Hero”, “Mimecraft”, “Unreal Fantasy”, “Shower Defense”, “Handy Crutch Saga”, “Grand Theft Lotto”, “Call of Booty”, “Resident E-mail”, etc. Your choice.

Create

We’re fortunate enough to do work where we get to create things with our minds. Don’t be afraid to break out your metaphorical “box of crayons”.