January 2009 Archives
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.
I’ve gone and adapted it to building software:
Write Code. Not Too Much. Lots of Tests.
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.
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.”
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:
- An online planning/tracking tool, like Trac (Python), Mantis (PHP), Basecamp (hosted), or XPlanner (J2EE)
- A wiki
- A shared Google Doc
- A whiteboard in a conference room
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
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.
There’s a big difference between “clean” and “empty” in web designs. I strive for the former and am awesome at the latter.
Some examples they give of good use of white space:
Here’s a bunch of links and books that I jotted down during CodeMash (which was awesome, by the way).
- ImageDraw (python)
- Image (python)
- typeface.js - web font replacement with javascipt (look ma, no flash!)
- pyshapefile - Python based tool for loading and visualizing GPS shapefiles
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
My nerd/software-engineering resolutions for 2009:
Contribute SomethingI’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 MoreI really need to practice what I preach all the time. Hopefully this will also make people like me more.
Post RegularlyI really need to get a posting schedule and stick to it. Maybe twice a week, minimum?
Build a Portfolioboth of sites I’ve created, AND code I’ve written.
Improve My EstimatingEstimating can always be improved. I think keeping some detailed logs of where I spend my time will help.
Get Familiar With Flash and FlexMuch 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.