September 2008 Archives

A Catch-22 for Software Projects

| Comments

I’m sure many people have hit upon this realization before I, but bear with me, I’m slow.


These two statements are completely incompatible:

  1. The end of the project the WORST time to change the design or refactor code.
  2. The end of a project is when you BEST understand the problem, and can produce the optimal solution.
As your project reaches the endgame, you want to be putting on the final touches. Fix bugs, performance test, get your deployment ready. Changing things, even slightly, can introduce wobbles and instability. The last thing you want is for things to be “good”, then do some refactoring that breaks features that have been built and tested.

Sadly, by the end of the project you’ve also become an expert in the space of the particular problem you’re solving. You can see flaws with the initial design, and ways to make the code more maintainable. If you had these piercing insights near the start of the project, it would be great; you could go refactoring everything without pissing anyone off. But at the end, things are delicate, and all you end up doing is saying things like “Ooooh, we TOTALLY should have done that part like THIS”.

I suppose this is an argument of scrum-style iterations, where there’s almost always a Next Time, and it begins with refactoring the existing solution.

The alternative is to never go back, and in doing so condemn all future peeps to maintenance hell.

What I Miss Most About Java

| Comments

I’m a Python convert. I like it, I love it. Yes, I want some more of it. But…


I still kinda miss Java sometimes. Here’s what I pine for most often:

Standard Deployment
Oh, how I yearn for the days when I could ant deploy something and have it nuke a database, reload records, run my tests, war up my application, deploy it, and restart the app server. If I was using the right IDE, all at the press of a button.

Built in Interfaces
Unit testing is simpler when there are interfaces from which to extend fake objects. You also get an early warning if you’ve screwed things up, because the dang thing won’t compile.

Zealous String Externalization
I know the Pythonistas will shout YAGNI!, but I miss having people go nuts for externalizing strings. String literals are trouble. You’re going to misspell them, you’ll foul up capitalization (or have to .upper() everything under the sun). In the  Javashpere, I was ridiculed if anyone spotted a double quote in my classes.

RELAX. I love python. It’s the violin to Java’s synthesizer. I just think each camp has something to learn from the other. 

I’ve spoken to a few people, and we agree that you could turn a Decent Java Programmer into an Awesome Java Programmer by having them sling Python for a year or so.

Promoting a release of code to test is like sweeping up after a dirty job. You need to clean out all the bugs, and when you think you’re done, go back and check everything again.


Back my formative high-school years, I worked summers as a landscaper. It was really messy. Dirt, mulch, sand, etc. By the end of a job, the customer’s driveway would be covered with crud. 

As a rookie, my job was to sweep up. So, I worked really hard my first time and swept the drive completely clean. I had done a masterful job. Not one speck of sand escaped my speedy broom.
“Good.”, said my boss. “Now sweep it again.”

To my surprise, the extra sweep picked up a small but substantial pile of dirt. I had been convinced I was done, but there was in fact a teeny bit more to do.

I think deploying software is like sweeping up after yard-work. You scrub all your bugs, marking them complete as each is committed, but in the end everything still needs at least one extra sweep before promoting the lot. 

I’m always a little surprised at what kind of things can go wrong, even when every ticket in the batch is marked “fixed”.