Lone Coder - Reflections for the Unsung Linux Saviours

Lone Coder: Fast Coders and Failed Projects

Tue, 23 Apr 2013 14:00:01 EST

Sometimes short-term cutting becomes long-term fail to deliver.

"When a man sits with a pretty girl for an hour, it seems like a minute. But let him sit on a hot stove for a minute â�� then itâ��s longer than any hour. Thatâ��s relativity!"

-- Albert Einstein

A man is going to purchase items from several stores. However, he is far too busy to waste time writing a list. So he travels to Store A, then to Store B, realizes he forgot something at Store A and must travel back there, then goes to Store C to purchase something he forgot. When he gets home, will the man brag about his efficiency? If he's a programmer, sometimes the answer is "yes".

Over the years, I've worked with several programmers and designers who believe they are exceptionally fast workers, and that speed shows their superiority. These are designers who don't do ask around about the facts before proposing a design. These are programmers that leave comments out of code to enhance their speed. Their designs are almost always failures, and the programs delivered late and faulty.

In the book "Game Architecture and Design", Rollings and Morris describe the problem this way: "The following are arguments against the introduction of architecture design procedures: there is no time for all of the delays and paperwork that it will cause, the project is already on an aggressive and tight schedule, and adding all this overhead will only slow things down in the long run. Having seen the poor states of projects that have succumbed to these arguments, the answer is that there is no time to implement the measures! Saving time in the long run makes up for any slowdowns in the earlier stages of the project." ("Game Architecture and Design", Andrew Rollings and Dave Morris)

Rollings and Morris describe the same arguments being employed to prevent code reviews, testing, team communication and other "optional" activities. Code reviews, for example, take up 1/40th of a two-week development cycle but can increase quality, train staff and improve productivity by 1/5th, according to the book. That's an 8-fold return on the investment over the course of the project. Many of these optional activities save time if dropped at the start of the project, but introduce costly delays later on.

I recently spoke with a game company recruiter who explained the difference between good programmers and game programmers. In games, he explained, it's all about ego. Most game programmers are actually terrible at what they do, but they are deluded into thinking they are the best in the world. A skilled programmer who is secure enough to have nothing to prove will always be rejected by game companies.

You can see this if you read "Game Programming Gems" book series by Charles River Media. The books contain articles written by people in the game industry. Some articles are insightful and clever, and some are misguided and uninspired and never should have been published. Yet every author is supposed to represent the best of the best, at least, in their own minds.

There is a disconnect in some technical people between their claimed skills and their actual skills. Often speed is used as the justification benchmark. It's easy to cut things out in order to be fast today, but difficult to keep things in that will make tomorrow even faster.

Sometimes companies can be under such deadlines and financial pressure that they get suckered by the sales pitch of technical people that justify themselves in terms of their self-proclaimed speed. Hiring someone who does shoddy work quickly, at least for a few weeks, gives a company a feeling of security, that their project will get delivered on time. But as the project advances, the deadlines begin to slip and nothing works properly, the time saving of these speed demons becomes questionable.

When you go shopping, it's worth it to take 10 minutes write a list before you start. That 10 minutes may save you an hour of time and gas. Sometimes short-term cutting becomes long-term fail to deliver.

April 23, 2013

Lone Coder: Linux Programming by Contract with GCC Ada

Fri, 15 Feb 2013 16:55:46 EST

An overview and first impression of programming by contract on GCC Ada.

Lone Coder: Comparing DAOs, ORMs and Other Ways to Use SQL

Fri, 21 Dec 2012 14:06:59 EST

Some problems are wolves: no matter what clothes you put them in, they still look like wolves underneath. In this article, I'll address the common problem of working with databases and explain why it is difficult to solve.

Lone Coder: Better Programming Productivity Through Dance

Thu, 22 Nov 2012 11:50:34 EST

A few months ago I issued a challenge to my fellow programmers: come to a free square dance open house. Could dancing teach programmers to work as a team?

Lone Coder: The Programmer's Guide to Car Buying

Tue, 16 Oct 2012 15:19:34 EST

Ask ten people what is the best car and you're likely to get ten different answers. Let's look at what I learned when I bought my last automobile.

Lone Coder: IT Architecture and the Benefits of Architects

Wed, 26 Sep 2012 10:10:09 EST

What exactly is information technology architecture and what do architects do?

Lone Coder: Slaves to Fashion

Tue, 22 May 2012 10:23:05 EST

Are technical people motivated, as Ellison believes, by fashion, choosing solutions that will impress peers or avoid ridicule?

Lone Coder: SparForte 1.3 Preview

Wed, 28 Dec 2011 10:10:38 EST

Version 1.3 will be add new features for "scaling up" your applications. Here are a few of the new features you can expect.

Lone Coder: Potato Chip Technology

Fri, 11 Nov 2011 06:35:35 EST

As the saying goes, you can't always judge a book by its cover. You can with open source.

Lone Coder: Unit Tests : An Pound of Prevention?

Thu, 01 Sep 2011 09:35:26 EST

People are bad at evaluating risks and payoffs. Unit tests benefits depend on the problem you are solving, the business requirements, the language you use and whether you are doing continuous integration.

Lone Coder: What's that Bug? Common Niagara Critters

Tue, 19 Jul 2011 10:06:56 EST

I'm tired of not knowing what to call critters around the house and yard. So I've done some Internet searching.

Lone Coder: Spectacular Failures: Firefox 4 and LibreOffice

Wed, 25 May 2011 14:39:31 EST

Firefox 4 and LibreOffice were Two spectacular failures, victims of their own success.

Lone Coder: BYOD: The End of Silly IT Contracts?

Sun, 10 Apr 2011 15:12:25 EST

Lone Coder: Why and When To Use Test-Driven Development Effectively

Wed, 15 Dec 2010 07:22:00 EST

There are several claims about TDD that questionable. The truth is, TDD is an effective way to fight aggressive schedules.

Lone Coder: My Daily WTF: The Server Outage

Sat, 20 Nov 2010 08:38:33 EST

Architects don't always make the right decision. People are human. But we can choose if we learn from our mistakes or keep repeating them.