The Wire. Down to it.
If you’re a big Critical Results fan–and who isn’t?–you may have missed my regular blog updates for the last week and a half. Let me tell you what’s going on.
process
The Saga of Lou
Sometimes projects are made to suck because people are cussed and they just won’t listen.
There was this time in late 1988. It was my first job out of college, with my freshly minted B.A. in Mathematics (!) and a lot of enthusiasm. It was a little financial services company just off East 9th and Euclid.
One of the first things they asked me to do was… kind of a drudge job. See, there was this database on our IBM System/38 mini. It had a file that included (among a lot of other fields) customer identifying information, balance due, and last activity date.
On dev software upgrades–when, why, how?
A few months ago, a client had made a few changes in some nifty little WinForms application I’d written for them and then wanted me to pick it up again from there.
I know that sounds like a nightmare, but the person who did the changes is really sharp, and he definitely improved on my work. So it wasn’t like I had to go and fix all the problems he introduced. There weren’t any.
No, I’m writing this because of a different complication.
Programmer optimism, and the "Death March"
I’m tired of hearing lines like “programmers are such optimists,” said in a disparaging way, by people who should know better. It’s a common refrain in corporate offices, usually when a software project is running late. Often the blame is placed on the programmers who are working for free on nights and weekends to make stuff work.
The project isn’t late because developers are braggarts. It’s because management has assigned them too much to do, which, as Peter Kretzman warns is the best way to not get what you want from your I.T. organization.
The “optimist” accusation is a cheap shot, and here’s why.
When it's Design Hell
What do you do when your project already sucks, and it’s already late, and the design you’ve been committed to is Hell?
Why pair programming is kind of cool
If pair programming feels threatening at first, you’re normal. Two developers, one keyboard… yuck. If you’re like me, you want your own space, and you get a kind of rhythm going with mid-compile checking email and stuff. Taking that away during pair programming time sounds like it would be incredibly awkward.
Good ideas in a Daily Scrum
Someone asked on LinkedIn the other day how to handle technical discussions in a Daily Scrum meeting that is ending early: do you use the free time, or defer the discussion for after the meeting?
To me, that’s an easy call. You do not have time for technical discussions in a Daily Scrum, the same way you do not have time to talk about last Sunday’s football game in traffic court. It’s not a matter of time, it’s a matter of focus and appropriateness.
Where does it hurt?
When taking on a new Project That Sucks, the most important thing for me to do first is to find out, in a big-picture sense, what has gone wrong. Why It Sucks comes before Making It Not Suck.
Sometimes it really is as simple as needing another bright software developer. Other times, the client can throw people at the problem but the problem is really structural: it’s set up to fail, and they should consider just dropping it. And still other times there’s a team or management dynamic that could use a push in the right direction.More
On Velocity, and Being the Chump
Last week, I mentioned my theory that most development teams have one person who just isn’t that great at getting things done. Like spotting the mark at a poker table, you want to figure out quickly who that team member is. In poker, it’s so you can take advantage of that person. In software development, it’s so you can set a kind of intuitive trust level: something between will this person make it harder to accomplish our goal? and can I count on this person’s tasks being properly fulfilled? with a little bit of how should I adapt my work style? in there.More
Lessons Learned
Yesterday, I finished up my part of a web development project, working with a team put together by a local software consulting company. Here are a few things I learned or had reinforced:
Figure out what the client really needs
A lot of times I pick up a project that’s a real mess, and the client thinks they need a supercoder to get it all done. I don’t think of myself as a supercoder, and even if I were such a person, the lack of one is usually not the problem. More often, when a software project isn’t going well it’s for reasons like these:
- redoing the same work
- poor choice of platform
- unclear goals
- not enough time allocated
- multiple agendas
- poor controls
- hoarding
- wrong kind of discipline
- reliance on heroics
- technical “bankruptcy” (when the code gets too complex to maintain)
What do these things have in common? They aren’t solved by supercoders.
You know what though? As I found it, this project had acquired good management and it had a very clear goal. Some of the specific requirements could have been better defined, but there was enough wiggle room that we weren’t really hampered by any vagueness. And our team lead, someone I’d happily worked with in the past, was very capable.
I could have applied some of my amazingly insightful make-your-project-not-suck magic, but no: what this project needed was a supercoder, or two or three. So I did the best I could in that regard.
I’m not talking about the “duct-tape programmer” type that Joel Spolsky lauds in his recent blog post. This website already had enough duct tape! It just would have been extra-awesome if I’d been able to understand the whole code base in a flash, and figure out how all the duct tape worked, rather than having to piece my mental model together one defect at a time.
Gauge the effort
In business terms, a key element for any independent consultant or small contracting firm is knowing how many technical people need to be on the project, and for how long. Nobody wants to be so overbooked they fail to deliver on commitments. Nobody wants unanticipated slack time.
At first, they told me it was a one-month “burst” kind of project. Then, based on burn rate, they scaled it back to three weeks. A bit later the client found more funding to make it five weeks. Then another burn-rate-related adjustment reduced my role to four weeks.
Does that sound awful? Maybe? It’s not. When it’s one of those park-yourself-in-a-cube-and-join-in endeavors, you rarely get that level of communication and adjustment. A lot of clients make it really hard to plan ahead. This one kept adjusting and communicating their time expectations, without being overwhelming about it. Cool.
Know who the chump is
They tell me it’s a truism in poker: There’s one chump at every table; you want to figure out who the chump is. Corollary: if you can’t identify the chump, it’s you.
The blunt truth is that in team software projects there is very often at least one person who hasn’t the skills to contribute much. That’s not always a bad thing: it can be a great opportunity for mentoring via pair programming, code reviews, or simply talking about how code gets done.
I really liked and respected the .NET developers I worked with on this project. On the downside, I couldn’t figure out who the chump was. I made my best effort, but I suspected that my process of understanding the existing code base was just taking too long. At the end, I realized that it took a month to figure out where everything was in this modestly complex system, which is about normal. Still, I hate that feeling: “Am I the chump? Really?”
Lunch strategically
One of the cool things about working at the client’s site is that it puts you in a geographic location that you can leverage. One of my Twitter pals works right upstairs from our war room. Another good friend works afternoons and evenings in the same office park. Our quality lead was a vague acquiantance from a project I did last year when he worked for a different organization.
So I got to optimize my lunch and snack time. I found out about new jobs opening up, in unrelated areas, for which other friends might qualify. I was able to refer my Twitter pal to two industry peers she didn’t already know. I got to hang out with, and get the latest relationship drama from, my office-park neighbor.
Those things wouldn’t have happened had I stayed in my home office or remained virtually connected via coffeehouse WiFi. It was a lot more driving than I like to do, and my car actually suffered, but at least there was that social benefit.
I’m just saying
It was a good engagement. The client is doing a lot better now than before we started, and their confidence will improve even more when the remainder of the team gets cracking on load testing and optimization. Congratulations all around!