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 --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Wednesday, March 25, 2009
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 --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
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 --
Software, SoftwareDevelopment, Computers, Programming
HTTP
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 --
Software, SoftwareDevelopment, Computers, Programming
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 --
Software, SoftwareDevelopment, Computers, Programming
HTTP
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 --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Saturday, March 21, 2009
Paper Pushing
Way back when I got started in programming, my high school did not have any computers, of any sort. So the programming was done on coding sheets, which were sent into the school district data processing facility, where some data entry clerks typed them in, presumably on cards, and sent the batch job to be processed. If we were lucky, everything was correct and we got back a result printout. If we weren't, we got back an error sheet and had to examine the code again to see where we went wrong. Usually it was a syntax error of some sort, so we re-wrote the coding sheet and submitted it on the next batch. I had one program that appeared to be un-typable - every clerk managed to typo something every try I made - the teacher finally let the program pass without running.
The next semester we got 3 Radio Shack TRS-80 computers, and we were freed from having to do coding sheets - until my college course in assembler, which was on punch cards - not a fun semester.
So for many years, I've been coding at the keyboard. But when I have a particularly hairy issue, I find myself going to a blank sheet of white paper and pseudocoding my way into the solution. I firmly believe that there is something visceral about writing that makes us more attentive to details. There are others who have a similar philosophy.
On the other hand, I've also fond that in some cases, typing is faster when I'm trying to get an idea out of my head and into a recorded form.
What do you think? Is writing code a quaint habit of old-timers, or a return to the core of the discipline?
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
The next semester we got 3 Radio Shack TRS-80 computers, and we were freed from having to do coding sheets - until my college course in assembler, which was on punch cards - not a fun semester.
So for many years, I've been coding at the keyboard. But when I have a particularly hairy issue, I find myself going to a blank sheet of white paper and pseudocoding my way into the solution. I firmly believe that there is something visceral about writing that makes us more attentive to details. There are others who have a similar philosophy.
On the other hand, I've also fond that in some cases, typing is faster when I'm trying to get an idea out of my head and into a recorded form.
What do you think? Is writing code a quaint habit of old-timers, or a return to the core of the discipline?
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Monday, March 16, 2009
Too Much Choice
An interesting point about choices.
One of my dislikes of Perl is this very thing - lots of way to do X leads to programs that use every way to do X in them.
One of the ways that choice makes our jobs harder is that every option needs to be validated somewhere in the code. Often this gets translated into masses of checks for all the options at every point of action.
Instead of this, you should strive to have things checked at the earliest opportunity, and then have the rest of your code assume that anything past the checks is valid and right. This limits your exposure to change, and makes the rest of the code flow smoother. It does tend to collect your checking code in the UI (or the interface to the UI), but it's a lot easier.
This also applies to the UI - don't give the user every option if they aren't all valid. Trim your menus of unactivated features; hide the checkboxes of custom features for the other customers.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
One of my dislikes of Perl is this very thing - lots of way to do X leads to programs that use every way to do X in them.
One of the ways that choice makes our jobs harder is that every option needs to be validated somewhere in the code. Often this gets translated into masses of checks for all the options at every point of action.
Instead of this, you should strive to have things checked at the earliest opportunity, and then have the rest of your code assume that anything past the checks is valid and right. This limits your exposure to change, and makes the rest of the code flow smoother. It does tend to collect your checking code in the UI (or the interface to the UI), but it's a lot easier.
This also applies to the UI - don't give the user every option if they aren't all valid. Trim your menus of unactivated features; hide the checkboxes of custom features for the other customers.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Sunday, March 15, 2009
Drowning In Code
Sometimes you have to work on old code.
(pause as the shock and cires of "Heretic!" die down)
Since not everyone gets to write only new code, you'll have to face this task many times in your career.
Here are two tips on how to approach it.
They both assume that you have limited documentation, obviously, since they promote looking at the code as opposed to looking at the documents; this is better anyway, since we all know that the docs are least likely to be accurate (followed closely by comments in the code)
Another good way to become familiar with the code is to look for something redundant that you can encapsulate into a method. This can lead to significant code reduction, making it easier for you to understand the remaining code.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
(pause as the shock and cires of "Heretic!" die down)
Since not everyone gets to write only new code, you'll have to face this task many times in your career.
Here are two tips on how to approach it.
They both assume that you have limited documentation, obviously, since they promote looking at the code as opposed to looking at the documents; this is better anyway, since we all know that the docs are least likely to be accurate (followed closely by comments in the code)
Another good way to become familiar with the code is to look for something redundant that you can encapsulate into a method. This can lead to significant code reduction, making it easier for you to understand the remaining code.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Subscribe to:
Posts (Atom)