yield thought

it's not as hard as you think

Posts Tagged ‘teams

Criminal Overengineering

As programmers we’re continually accused of doing a sloppy job. There are countless programs in the wild, crashing, locking up and accidentally writing “I am a fish” a million times over someone’s mid-term essay. The effect? Something like this:

This damn computer and excel r fuckin my life up! Hatin life right now
MissAlauren (and everyone else at one time or another)

It’s experiences like this that cause people to rant about Microsoft and curse the anonymous programmers who suddenly (yet inevitably) betrayed them. We all know this; it’s burned into our very souls by countless hours of tech support provided to family and friends. Time after time we see that programmers who do quick, sloppy work make other people suffer. And so we try, we try so damn hard not to be like that. We try to be the good programmer who checks every return value and handles every exception.

If we stopped at competent error handling and sufficient testing, all would be well. In truth, we actually go too far and, it has to be said, largely in the wrong direction.

vast proportion of software at work today is horribly over-engineered for its task. And I’m not talking about the interfaces, about having too many controls or options for the users. These are, indeed, terrible sins but they are the visible ones. The worst of the overengineering goes on under the surface, in the code itself.

You’re Doing It Wrong

Have you ever seen someone using the strategy pattern when they should’ve used a 5 line switch statement? There are a million ways to turn something like this:

switch(operation)
{
case OP_ADD: return a + b;
case OP_SUBTRACT: return a - b;
case OP_MULTIPLY: return a * b;
default: throw new UnknownOperationException(operation, a, b);
}

… into a hideous, malformed mutant beast like this one, which I haven’t inlined because it’s far too long.

The most insidious cause of overengineering is over-generalizing. We will over-generalize anything given half a chance. Writing code to work with a list of students? Well, we might want to work with teachers and the general public someday, better add a base People class and subclass Student from that. Or Person and then EducationPerson and then Student. Yes, that’s better, right?

Only, now we have three classes to maintain each with their own virtual methods and interfaces and probably split across three different files plus the one we were working in when a one-line dictionary would have been fine.

Perhaps we do it because it’s relaxing to rattle off three classes worth of code without needing to pause and think. It feels productive. It looks solid, bulletproof, professional. We look back on it with a comforting little glow of self-satisfaction – we’re a good programmer, no messy hacks in our code.

Except, this doesn’t make us good programmers. Overengineering like this isn’t making anyone’s lives better; it’s just making our code longer, more difficult to read and work with and more likely to contain or develop bugs. We just made the world a slightly worse place. It lies somewhere between tossing an empty drinks bottle on the street and grand theft auto.

The extra effort caused by our overengineering carries a hefty opportunity cost:

  1. Less time spent refining the user experience
  2. Less time spent thinking about the meaningful implications of the feature we’re working on
  3. Less time available to look for bugs and – with harder-to-read code – more time spent debugging them

Yes, by overengineering the Student class you indirectly ruined MissAlauren’s day.

We have to stop championing each ridiculous feat of overengineering and call it what it is. It’s not ‘future-proof’, because we can’t see the future. It’s not robust, it’s hard to read. Applying a generic solution to a single case isn’t good programming, it’s criminal overengineering because like it or not somebody, somewhere will pay for it.

Don’t Worry, Be Happy

I suspect all the best programmers have already realized this, but they’re not shouting about it loudly enough for everyone else to hear. Paul Graham is completely right when he suggests that succinctness is valuable:

Use the length of the program as an approximation for how much work it is to write. Not the length in characters, of course, but the length in distinct syntactic elements– basically, the size of the parse tree. It may not be quite true that the shortest program is the least work to write, but it’s close enough… look at a program and ask, is there any way to write this that’s shorter?
— Paul Graham, The Hundred Year Language

He’s actually talking about language design here; indeed, in Succinctness is Power he’s careful to note that it’s clearly possible to write a program that’s too succinct. This is because, these days, Paul Graham is more a language designer than a working programmer. Otherwise he might have said:

If you’re about to take a hundred lines to write what you could in ten, stop and ask yourself this: what the fuck?
— Mark, Criminal Overengineering

When I feel tempted to over-generalize or over-engineer a bit of code, it’s often because of fear. Fear that someone will find a really good reason I shouldn’t have done it the easy way. Fear that I’ll have to rewrite the code again. Fear of finding myself on the wrong side of an argument about the merits of the visitor pattern. But fear does not naturally lead us to the most elegant solutions.

Next time you feel the compulsion to write a nice, general solution to a simple case, stop and ask yourself what’s stopping you just writing it the simple, specific, succinct way:

  1. Am I worried I’ll have to rewrite it?
  2. Am I worried someone will criticize it or that I’ll look bad?
  3. Am I worried that it’s not professional enough?

Are any of these true? Then relax. Don’t worry. You worry, you call me, I make you happy.

Just write the code the simple, specific way and then add a short comment, something like: Replace with the Strategy pattern if this gets any bigger.

This is the perfect solution. It’s a great reminder to you next time you come here about what you wanted to do. It shows other programmers on your team that you considered the ‘correct’ way to do it and have a good reason not to do it just yet. It’s very hard to argue with a comment like that, because you’re not arguing about the strategy pattern vs the switch statement, you’re arguing about whether to use the strategy pattern after 3 cases or after 4 cases – not a discussion that can reflect badly on you, in any case.

A few months later you can go back and look at how many of your comments eventually turn into more complicated, engineering code. I’ll bet you it’s not very many. That’s how much time and effort you’ve saved, right there. That’s setting yourself free to pursue the solution and that’s making the world a slightly better place.

Note: Yield Thought has moved to http://yieldthought.com – check there for the latest posts!

Advertisements

Written by coderoom

June 23, 2010 at 8:15 am

Posted in Programming

Tagged with , ,

The Best Comment Ever (No, I Didn’t Write It)

with one comment

Disclaimer: I didn’t write this and take no credit for it whatsoever. edw519 wrote it as a comment on Hacker News, which you can see here: 3 Simple Rules That Will Make You a ‘Superstar’ Developer – or at the time of writing on the wonderful HN Best Comments page. However, I’m terrified that this zen-like jewel will become lost in comment-page obscurity. Also I want an easy way to link to it, so here it is without further commentary:

A smart accountant once told me that the answer to “How much money did you make?” is always, “Who wants to know?” If it’s an investor, the answer is “A lot.” If it’s a customer, the answer is “A little.” If it’s the IRS, the answer is “None.”

Same thing here. The answer to “Who is a superstar developer?” is always, “Who wants to know?”

To a project manager, the programmer who hits every deadline (regardless of quality) is a superstar.

To a customer, the programmer who solves their problem quickest is a superstar.

To a business owner, the programmer who makes them the most money is a superstar.

To a PHB, the programmer who makes them look the best is the superstar.

To a journalist, the programmer who tells the best stories is the superstar.

To a junior programmer, the best mentor is the superstar.

To another programmer, the programmer they are most likely to want to go into battle with is the superstar.

— edw519, writing an incredible comment on an otherwise unworthy Hacker News story.

Written by coderoom

February 1, 2010 at 7:58 pm

Posted in Programming

Tagged with , , ,

3 Simple Rules That Will Make You a ‘Superstar’ Developer

with 49 comments

So you’ve read Joel’s posts about how 1% of developers are 10x as productive as the rest; the superstar developers; the only ones worth hiring. You know you can program, that you’re reasonably talented, but that’s not enough. You want to be 10x as productive as everyone else in your company? You want to be the guru everyone else comes to when they’ve got a problem, the guy who takes one glance and puts his finger on the problem right away?

You can. Just follow these 3 simple rules and within 12 months all this and more will be yours.

Rule 1: Write lots of code. Have to fix a small bug in an area someone else has written? Don’t waste time trying to understand it or their motivations for writing it that way. Just rewrite the lot as you think it ought to work. Call it refactoring if anyone asks.

Rule 2: Write your code quickly. Touch lots of files, and include every one of them in the ChangeLog. Don’t worry about accidentally introducing hard-to-find bugs; they’ll actually help you later on, as long as they’re actually hard to find. Avoid introducing trivial bugs.

Rule 3: Don’t take time to document your code, or add little comments explaining potential pitfalls in modifying some of the less clear statements you’ve introduced. You don’t need them, you wrote the code.

Dilligently following these three rules will make you the superstar in your team within 12 months. Write them out and stick them up. Not in the office! Somewhere private. Repeat them to yourself every day before you start work. They may seem controversial, but trust me, everything has a deeper underlying reason.

How do I know this works? Because I’ve done it myself and because I’ve seen others do it. Of course, I didn’t realise I was adhering to the Three Rules at the time – I was young and naive and thought I was just trying to do my best for the project. It’s only now, many years later, that I am able to reflect and draw upon the wisdom of the experience to share with you like this.

The 3-Rule Programming Supremacy system is based on one technical principle and one social principle.

Technical Principle: You’re 10x as productive when you’re working on code you wrote as on code you didn’t write.

Everyone understands their own code best. It’s part memory, part convention – that is, everything follows your convention. You expect a function to be called X and it is. You look in class Y to find the functionality and of course it’s there. It’s even at the bottom of the file, where you’d have added it. All these little things add up. You don’t need to worry so much about unintended side-effects when you modify something, because you remember the places that were somewhat risque and know instinctively where you would do careless things and where not.

In short: if you wrote the code, you have an almost perfect model of the code in your head, because that’s what you used to write it.

Social Principle: Your programming ability is judged by how much code you write, how quickly you finsh features and fix critical bugs and how often your insights are necessary to solve problems.

These two principles define the problem space – or, as we shall call it – The Game. You win The Game by improving your reputation to superstar guru levels. To improve your reputation, you need to improve the speed with which you write code, fix bugs and help others. The technical principle tells us how to achieve that – by working in our own code as much as possible. Indeed, by converting as much of the project to our own code as possible.

The 3-Rule System is a foolproof strategy for achieving that.

By following rule 1, you will quickly get to know a large amount of the codebase. Most importantly, you won’t waste time trying to understand other people’s code, which is a difficult and time-consuming process.

By following rules 2 and 3, you maximize your rate of code-conversion by avoiding the most time-consuming parts of writing good code. It’s vitally important that you are touching more code than the rest of the team combined.

There are also beneficial social aspects to working like this:

Benefit 1: Everyone will see how quickly you’re committing huge chunks of code and will start to respect you – especially your boss, who has no other metric to judge you on other than commit frequency and volume.

Benefit 2: Although you’ll introduce lots of new bugs like this, it’ll be several months before they start showing up, by which time your reputation as an expert programmer will already be assured. You can now profit a second time from them by fixing them faster than anyone else. Your colleagues will take 10x longer than you to track each one down. Increasingly, they’ll ask you for advice or help because you wrote that bit of code. Be friendly, humble, happy to help. You’ll spot the bugs very quickly. Your guru reputation will grow day by day.

You can view the process as analagous to a real-time strategy game. The world map is your project’s codebase. The regions you wrote are generating you resources; the regions owned by others are generating them resources. Your resource, here, is programming efficiency, as you’re 10x as productive when dealing with your own code as with someone else’s. Being seen to be 10x as productive gains you reputation, which is the point-scoring mechanism in The Game.

Clearly if you own very little code, you aren’t going to be gaining much reputation because most of the time you’ll be working with other people’s code at the same rate as anyone else would. Time to change that.

Rule 1 is the basis for your economy. You become a superstar by owning more code in the project than anyone else. You invest in your economy by writing new code, or converting existing code to your own, because every area of code you own generates you productivity and reputation.

Rule 2 is aggressive. Expand into other people’s areas and modify their code to make sense to you. Let people see that you’re touching a lot of code – it is good for your reputation. However, you have to be careful when going on the attack. Rewriting code carries a certain reputation penalty, but more about that later.

Rule 3 is defensive. Make it difficult for other people to work in your code or fix bugs in it – for every hour they spend fixing bugs you’ve accomplished another hour of fresh code rewrite somewhere else, thus increasing your control over the board.

Never forget that this is all about gaining reputation. It’s critical not to over-extend yourself and appear as if you’re harming the project. It’s equally important to remain on excellent terms with your opponents^H^H^Hcolleagues, always being polite, helpful and humble. Your reputation determines how much of the codebase you can convert and which parts you can convert without incurring negative reactions.

To this end, you must start small, in the most hated, ugly area of code in the project. Just go in there and rewrite it all to make sense. Don’t worry about all the bugs you’ll introduce; people will be glad that you’re brave and bold enough to take the project on and will agree that it needed doing and that bugfixing the new code will be easier than maintaining the old code.

When you’ve finished, you’ll find your reputation has increased. You’ll be able to rewrite slightly less hideous areas of code without people asking if that really needs to be done. Eventually your reputation will grow so large that you can rewrite core application functionality at will. By then, you’ll know far more about the rest of the system than anyone else and will introduce surprisingly few bugs. This will assure your guru staus as superstar of the team. This is your end-game. You have won!

Postscript for the naive: This post is a mild satire on programming in teams. These three rules, while undoubtedly effective, are evil. They harm overall project progress for your own benefit. They don’t make you a better programmer intrinsically, only compared to the rest of your team. You may, like I and countless others, have done something like this completely innocently in the past, when you didn’t know better. Now you know better.

Postscript for project managers: If your environment meets the grounds for the Two Fundamental Principles, then you will get programmers playing The Game and your project will suffer. Change the rules. Make sure that programmers are recognised for playing nicely with each other’s code, for working in small teams on larger problems. That rewriting for the sake of it is frowned upon, or that the bugs it introduces are traced back to the rewrite that caused them. I don’t know what the right way to get away from this is. If you do then please, for the love of all projects everywhere, leave a comment!

Note: Yield Thought has moved to http://yieldthought.com – check there for the latest posts!

Written by coderoom

January 28, 2010 at 1:43 pm