January 2009 Archives

I caught wind of Uncle Bob’s ire via Jurgen’s tweet. It’s worth looking through how Bob takes them to task.

[link]:“Quality Doesn’t Matter That Much” — Jeff and Joel

The Tactical DBA

| Comments

Many developers know the database administrator as a curmudgeon who’s favorite word is “no”. DBA’s aren’t mean or grumpy at heart; they just want stability and order. They succeed when the database stays up and get fired when it goes down.

When brash developers come along and change things, it threatens stability, and they deny, or at least grumble about change. This is good for stability but not great for project velocity.

I like the idea of having a tactical DBA on the project team. The TDBA is responsible for things like:

  • Creating tables based upon the domain model
  • Implementing good indexes
  • Tuning queries
  • Managing ETL tasks
  • Making other DBA’s feel good

I’ve worked on teams with a dedicated DBA, and it is awesome. Application developers don’t have to slow down to dust off SQL skills or negotiate with the omnipotent DBA. Everyone can do what they’re good at, and progress is accelerated.

Sadly, it’s a hard to convince managers that a team deserves a whole DBA just for their project, but I think it’s a pitch worth making.

Here’s a great presentation on creativity and patterns by Merlin Mann. He gives a great intro to what patterns are at their core, which is kind of refreshing. Even if you think pattern is a four letter word, it’s worth watching.

[via]: Video: Merlin’s Talk, “Toward Patterns for Creativity”
[via]: Macworld Pulse: Merlin Mann

In the spirit of recent comments, I’m opening up discussion on code/food comparisons (thanks Matt).

To start things off, I’ve come up with one of my own:

Please add your own comparisons in the comments!

In his New York Times essay “Unhappy Meals”, Michael Pollan outlines a manifesto for eating right: Eat food. Not too much. Mostly plants.

I’ve gone and adapted it to building software:

Write Code. Not Too Much. Lots of Tests.

Write Code

You need to keep up to date with building software. That means participating in the act of coding. If you’re an architect, senior engineer, or development manager, you’ve got to do it.

Not Too Much

This is the essence of lean development. Only build what is needed. Cruft and verbosity are evil.

Lots of Tests

Testing is the key to quality software. If you aren’t writing tests, your’e doing it wrong.

This is a simplification, but a useful one. If you’re lost, overwhelmed, or pissed off, try reciting this a few times (when nobody’s looking). You might feel better.

Don’t use a spreadsheet program like MS Excel to track and plan your team’s to-do items. Yes, it gets the job done. Yes, it’s easy to sort and print, and yes, it’s probably already installed on your computer, but I urge you to resist the temptation. Here’s a few reasons the spreadsheet is a sub-awesome planner.

Poor Collaboration

If you’ve figured out how to effectively use the “share workbook” feature, I’m all ears. Most of the time I’ve seen this devolve to “Patrick is in charge of the spreadsheet, so nobody go into the share drive and edit it!”. Not to mention the pervasive “Oh, I have a different version printed out.

No Relationships

There’s value in breaking large tasks into smaller ones. Sadly, in a tabular format, representing this in Excel is tricky. How do you show the supertask’s progress based on subtasks?

Spreadsheets Are Volatile

Excel wasn’t built to be a standalone application. There’s nothing to keep people from spawning tons of copies, deleting it forever, or fouling it up. Most teams will scrap whatever format they use on one project and reinvent it on the next. There’s no chance to compare the metrics of how long things took from project to project.

As possible alternatives I humbly suggest:

In the end, your tool doesn’t have to be fancy. What’s important is that you put some rigor around your tracking. People will take the tasks and tracking more seriously when there’s a solid tool behind it, and they know their information will be an input to the next project’s planning.

I’m a former Java boy, so sometimes things in python that are similar to, but not the same as Java confuse me. Like yesterday when I wondered about the difference between staticmethod and classmethod.

Luckily a coworker quickly sent me a link to a description of staticmethod vs. classmethod, thus saving me two minutes of internet searching.

Estimator for Web Projects

| Comments

Astuteo’s estimator is essentially a glorified spreadsheet for calculating time and cost for web projects. It also lets you add your own items and produces a print version.

I came across a great vim macro that shows you lines longer than 80 columns.

After using it for a bit, I realized that showing a the foul line down the entire page, like many editors do, is overkill. You only need to know about the line limit when you’ve exceeded it. Why show the line all the time?

This macro gives the clear visual cue only when you’ve broken the rule.

White Space and Web Design

| Comments

There’s a big difference between “clean” and “empty” in web designs. I strive for the former and am awesome at the latter.

Here’s a post about using white space effectively on web pages.

Some examples they give of good use of white space:

I’ll come clean. For all my infatuation with Scrum, , Agile, and Extreme Programming, I had not actually read the Agile Manifesto. Turns out it’s pretty sweet once you get past the craptastic background image.

I printed it and tacked it to my cube.

My CodeMash Reading List

| Comments

I'm Tweeting. Rejoice.

| Comments

I’ve fired up my twitter account. Please follow and bash me.

Today I was led astray by an evil person making mischievous use of the “edit” feature on Google Maps.

We were on our way to CodeMash by car, Google Map printout in hand, and arrived in Sandusky. We started zeroing in on the Kalahari. As we followed the last few lines of turns, we realized the directions were taking us into a dingy neighborhood far from anything resembling commercial civilization.

The last instruction dumped us at this awesome dead end:

Thankfully Mike had his iPhone handy, and we were able to find our way to the correct location.

When we finally arrived, I repeated my initial map search. This time I noticed the little “edited” label on the top two matches:

Agile Advice recently posted a link to an old (1996) article from Fast Company discussing how software for the Space Shuttle is produced.

The article profiles the people who write the code and their methods, and bullets out some of the axioms by which they work.

One of the more interesting tools is a program that calculates how many errors should be present in a given release. Then, even if things look ok, they keep testing until they hit the predicted bug count.

Like computer models predicting the weather, the coding models predict how many errors the group should make in writing each new version of the software. True to form, if the coders and testers find too few errors, everyone works the process until reality and the predictions match.

At times, the article chastises us young punks for dressing down and writing buggy code. While I alway appreciate a dose of humility, I think there’s a big difference, both in budget and goals, between launching a REALLY expensive rocket with people in it into space and rolling out a cool new web search.

Nonetheless, it’s a very interesting read, and worth the time.

[link] They Write the Right Stuff

I Resolve...

| Comments

My nerd/software-engineering resolutions for 2009:

  • Contribute Something

    I’m always using freely available software and packages, but rarely contributing back. I may not have the chops to build anything really new and kick-ass, but maybe I can help with test coverage or something.
  • Talk Less and Do More

    I really need to practice what I preach all the time. Hopefully this will also make people like me more.
  • Post Regularly

    I really need to get a posting schedule and stick to it. Maybe twice a week, minimum?
  • Build a Portfolio

    both of sites I’ve created, AND code I’ve written.
  • Improve My Estimating

    Estimating can always be improved. I think keeping some detailed logs of where I spend my time will help.
  • Get Familiar With Flash and Flex

    Much as I often badmouth it, Flash is a web reality, and isn’t going away soon. Time to stop complaining and start learning.

So there they are. Feel free to call me out on them over the next twelve months.