Tuesday, April 14, 2009

Anti-Heroism

In an earlier post, I mentioned the bad effects of a culture of heroism.  Making a virtue of excessive overtime rewards reactive instead of proactive programming;  it cuts into the testing of the product; it erodes morale.

It's a death spiral in most companies; managament stops recognizing the normal limits of work and starts to expect more and more.  This is especially likely in companies that do not accurately track developer hours - if the management does not get a complete count of the time spent on development, they will assume it was done in a 40-hour week, and so they think that the next project can be accelerated by  getting the developers to work a few more hours.

So when 5'o'clock rolls around, wrap up what you're working on, prep for the next day, and GO HOME.


Technorati Tags --
, , ,
HTTP

Sunday, April 05, 2009

A Followup on Automated Testing

A few posts back I described a blog post I had read about a shop that was stating they did 50-60 live deployments per day.

Here's a post about someone who went and looked at the system being deployed.



Technorati Tags --
, , ,
HTTP

Saturday, April 04, 2009

Several Lists to consider

I've accumulated a number of "Top N X" lists over the past few months, so I decided to bundle them all together into a single post for your perusal.  I cannot vouch for any specifics in any of the lists, but they are probably useful at the least.


Coding practice sites - these are good for your Code Kata (and Code Kumite)
Seminal Computer Science Papers - you should always know the foundations of your discipline
Some recent programming books - now that you know the foundations, look to some cutting edge work
Good blogs about programming - keeping abreast of the latest news in the profession. (The list is incomplete - it's missing this blog :)

So read and enjoy, and hopefully you will find things you can use.



Technorati Tags --
, , ,
HTTP

Wednesday, March 25, 2009

A Different Type Of Hacking

Although we all typically found adding code to a system, one of the funner parts is removing code.  I love it when I can cut whole swaths of code out of a system, combining duplicate code into a common function, deleting unused methods, slashing commented-out junk.

And sometimes you get the chance to rewrite some code, and sometimes you have to


Technorati Tags --
, , ,
HTTP

Tuesday, March 24, 2009

Another Take on Technical Debt

Most of us should be familiar with the idea of Technical Debt, but it's not always clear how it fits into the long-term view of a project.  Here's Martin Fowler's concept of Design Stamina - showing why Technical Debt tends to accumulate; there is a point in the life of a project where TD is a useful thing to grow, but there is a point where it becomes a liability.


Technorati Tags --
, , ,
HTTP

Monday, March 23, 2009

Social Skills In Developers

We all known at least one of them.  The prima donna, the ego on legs, the one developer who is famously skilled, but is, to put it bluntly, an asshole.

If you're one of them, you probably need to stop reading now.

If you've got one on your team, you probably need to get them out of your critical path.

Despite our professions acceptance of heroism, the presence of a toxic person can kill a team, or
 a project, or a company.

The biggest risk is to your team - you risk alienating all the rest of them, and at some point, you will piss off your resident genius and will have nobody to turn to to save your ass.



Technorati Tags --
, , ,
HTTP

Sunday, March 22, 2009

Metric System

One of the larger conflicts between programmers and management is on how to measure programmer value - who is a good programmer and who isn't.  Aside from the ego and paycheck issues, it's still a touchy subject, usually because the metrics that management usually chooses to use are typically measuring the wrong things.

One of the oldest metrics is Lines of Code (LOC, or more commonly KLOC).  Now, KLOC may be a good way to compare the complexity or effort, after the fact, of a team's work on different projects, but it's not a good measure of individual programmer productivity.  There are just too many variables.  It's also very easy to game the numbers - if your boss is going to rate high KLOC numbers as good programming, your programs will be longer.

That's another point - programmers are very good at recognizing the rules of a system and gaming them.  Given the strong correlation between programming and role-playing games, it's foolish to think that we won't find a way to mini-max the metric.  KLOC? Put everything on its own line.  Function Points?  Every method will be as complex as possible.  Etc, etc.  The only way to have accurate metrics is to decouple them from programmer pay and promotion.

So what if you need to measure improvement?  Here's one option, and another.  And in case you need ammunition to get off a Death March, there's this.





Technorati Tags --
, , ,
HTTP