Hats, that is. Not rings…
Recently, I was asked to provide a specification and estimate for a project at work. I’m not a software architect, so I’m having a hard time with some aspects of the spec – I think I know what we should be doing, and I think I have a grasp on best practices for what we’re trying to do, but I don’t know for sure… And estimates? Forget it. Remember how Scotty lets McCoy in on his little secret of multiplying everything by three so he’s always done early and looks like a genius? Yeah. I appear to have a knack for dividing by three and using that for my number.
So I picked up a book and started to read. How I spent my Christmas Vacation…
Snark aside, I’ve been a fan of Steve McConnell since his first edition of Code Complete. But Software Estimation? Parts of it read like a post mortem of projects of ours that have gone pear-shaped. Very compelling stuff, it was. So I started to pull together data on our past projects, including asking The Boss[*] for payroll data on effort expended for various projects. I downloaded NDepend to get method counts and lines of code. I began pulling together data from our bare-bones bug-tracking software on defect counts, and staff-hours per defect. But I wasn’t going to get the payroll data without a decent explanation. I mean, The Boss is accessible, and very willing to share information, but still… It’s payroll, even if I only want sanitized data from it. I explained to him what was going on, and he agreed to a meeting so we could discuss what I was trying to achieve.
I need to back up a bit here; some of y’all already know this stuff (some of you know it more intimately than others), but it bears repeating. We’re a small company, and software development is a very small part of our business. Most of our coding work is really classic consulting-style work: a client comes to us with a one-time problem, we leap into the fray, hack away at their code until it resembles something more or less approaching what they want, they pay us, we leave in a cloud of dust kicked up by our horses, whooping and hollering, six-guns blazing into the sky. Yee-hah! Pow! Blam! Who were those masked coders?
Yeah. For consulting, sure; for developing your own products… not so much.
I mean, some companies do work this way, churning through developers like they’re a commodity. Most flame out eventually; some manage to achieve the breakthrough that they need to get their product to market and then they mature into a less destructive environment. Some are big enough or rich enough or glamorous enough that they’ve got coders practically begging to be chewed up and spit out. (Or swallowed. Not sure which is the better option.) But we don’t work that way.
Unfortunately, our way of working… wasn’t. Not consistently, anyway. And it’s something I’ve talked about with one of the other developers who has been with the company a lot longer than I have. We don’t have a good bug-tracking system, we don’t have an automated build environment, we don’t do any kind of automated testing. We’ve been treating our products as consulting projects, not paying attention to revisions and releases and versions. Need a new version? Copy the old code base into a new project! Whee! Your idea didn’t pan out? Don’t delete it from the project! Just leave that dead code in there, begging to be used by someone who doesn’t realize it’s dead! Check in files? Why? I’m the only developer on the project right now! We’ve got some files in our version control software that have been checked out for years. In some cases, the specific mappings don’t even exist any more because the computers they were checked out to have been retired. We have project-specific code contaminating other projects. We have… eh. You even if you don’t work in software, you should get the picture.
As a company, we’ve tacitly acknowledged that this is a problem, but (as far as I knew) we weren’t really prepared to do anything about it. It would cost too much, it would take too long, it would take resources away from the current
crisis project – I’m sure y’all can fill in the blanks. And I was prepared to incorporate all this into the meeting.
The meeting went well. We had a frank discussion of the full range of weaknesses in our software project management. He mentioned that he’d considered hiring a software-specific project manager to help achieve all this, but that hadn’t really gone anywhere. He was very receptive to the estimation technique, and we discussed what information would be most helpful to test it out. He also showed me some of the systems that the company has developed for successfully tracking expenditures and effort on other, non-software, projects and briefly talked about adapting those for our software work. I’d have to call it time well spent.
As we were wrapping up, he brought up the software PM again, and that this was an open position, and how involved did I want to be in the process of finding this person and/or developing these systems?
Looking back on my career, I’ve come to significant crossroads more or less every five years, almost like clockwork. And for the past year or so, I’ve been expending a fair amount of cycles trying to figure out how to fix some of the systematic problems in our development processes. To be sure, they’ve been intermittent cycles, but I’ve been expending them anyway. And I’ve been expending them more and more lately, with effectively a zero chance of getting anything done. So… crossroad, or just a suck-up-and-deal/company growth pangs moment?
How involved did I want to be?
Well, I said, as much as I like coding, and I do like coding, and as little as I could ever see myself as a manager, I’d like to be involved. Very involved.
Okay, says The Boss. That sounds like a different meeting. I’ll get that data to you, and we’ll talk soon.
Looks like a crossroad after all. File this under “To be continued…”, I guess.
*The Boss? The Owner? Main Guy? (That’s what his business card says, anyway. I suspect he’d let me put Code Monkey on my business cards if I ever had a need to order them…) Maybe his initial? We’re small enough that titles are more for external consumption than anything else… Otherwise, it’s all first names, all the time. [back]