For 3-1/2 months, we’ve been using a scrum board — not the one in the photo, but similar — to track tasks on a development project. Tasks start out on the left side of the board in a Not Started column, then move through In Progress, Code Complete and User Testing on the way to Done. Today someone said, “We need a list of everything that still needs to be done — like the scrum board, but could you put it in a spreadsheet?” Ummm, I could, but it wouldn’t contain any additional information than what’s on the board. That was an eye-opener to me. I like the scrum board format because it keeps things visible. It’s easy to see what all the tasks are and it’s easy to see the status of each task. It never occurred to me that if you record information on Post-Its and stick them… Read more →
Author Archive: The Programmer
Occupational Intensity
I saw a guy yesterday — let’s call him Jack — that I used to work with 20 years ago on my first programming job. My most vivid memory of him is the day he offered to sock another programmer — let’s call him Sid — “right in your f^$&ing face, Sid” because Jack was unhappy with the quality of Sid’s work. You rarely see that kind of passion and zest in the workplace anymore . . . Thus spoke The Programmer. Read more →
The V Model
The graphic on the right came up for discussion at the office today. The V Model is a traditional model, still widely used, but (IMO) bad for at least a couple of reasons. Look where User Requirements and UAT are — the first and last items in the V. This ensures that the maximum amount of time goes by between users saying what they want and being able to test out the implementation. The more time that goes by between users saying what they want and being able to try it out, the more likely it is that they’re going to change their minds, for any number of reasons. That’s bad. If our testing is honest, there’s always some non-zero probablilty that the system will fail, again for any number of reasons — too slow, too buggy, not what I asked for, etc. By putting testing last, we don’t find… Read more →
Free Advice for Women Considering an IT Career
I’d just finished reading another tiresome “why oh why aren’t there more women in IT?” article when I found a former colleague on LinkedIn . . . he lists his job title as “Analyst, Software Quality Assurnace.” Would you hire him as a QA guy? I wouldn’t, and that’s even before I saw how he misspelled “Assurance.” The IT “profession” is chock full of idiots like this. Why anyone thinks women are missing out on something if they don’t work in IT is a total mystery. If I had a daughter, I would tell her to be a meeting planner or a flight attendant . . . Thus spoke The Programmer. Read more →
Things That Pop Up and Poke You in the Eye
We’re discussing whether our organization will use a popup user survey on our web site . . . “I propose doing the survey without the popups,” I say. “That’s why browsers have popup blockers, because people don’t like popups. A popup is like a poke in the eye. I don’t like it when things pop up unexpectedly and poke me in the eye. Whenever that happens, I make sure not to go back to that place anymore.” Unfortunately, no one picks up on the “popped up and poked me in the eye” motif because I was then going to chide them for their junior high school mentality. “I had a teacher who used to say that,” a young woman says. “‘It’s better than a poke in the eye with a sharp stick.’” I say, “I used to work with a guy who said, ‘You can’t beat that with a sharp… Read more →
Death of a Programmer
I’m reviewing my year-end Benefits Summary at work . . . I’ve got life insurance plus supplemental life insurance at a multiple of my annual salary. I’m having a Willy Loman moment where it seems like after all the highways, and the trains, and the appointments, and the years, you end up worth more dead than alive . . . Thus spoke The Programmer. Read more →
I Had a Great Meeting
I had a great meeting today — eight women plus myself. That’s not why it was great though. These ladies want to launch an online Education Room with webinars, a speaker directory, announcements of upcoming events . . . they have none of the content ready . . . and they want to launch it on Jan. 1, 2009. So instead of talking about how they’re planning to get the content to me so I can build the thing, they’re saying things like, “When you hover over a webinar link, it will display a description of the content — like on Netflix . . .” Netflix. Right. So I say, “You’re not gonna get that.” Oh, they loved it! They laughed and laughed. They knew it was ridiculous, they just wanted someone to tell them it was ridiculous. Women love a masterful man who’s good at his work. Thus spoke… Read more →
Declinations
I’m going to start declining invitations to meetings that have vague goals; a long list of invitees who don’t know how to come to the point; a moderator who doesn’t know when to cut people off. Thus spoke The Programmer. Read more →
I Hold in my Hand a 63-Page Requirements Doc
I hold in my hand a 63-page requirements doc . . . We spend a lot of time reworking the requirements doc to reflect the reality of the system that we’re actually building. We also spend a lot of time reworking all the docs that derive from the requirements doc — design docs, UI docs, test plans, etc. — to reflect the changes in the requirements doc. Another way to think of this is that the project is driving the requirements, rather than the requirements driving the project. So why did we create all these incredibly detailed documents in the first place? We have a vast collection of well-documented ignorance . . . Thus spoke The Programmer. Read more →
Why I Got Into Management
My first 10 years in the software business, I had great managers. They did the management thing and I did the programming thing and we got great results together. Then, after the dot-com boom torpedoed industry hiring standards, I got tired of working for managers who should not have been allowed anywhere near a software project, people who were not fit to direct a professional software developer to a table at the Olive Garden, much less direct their activities on a complex project. I couldn’t possibly have continued to work for people like that — it just made a mockery of all the work I’d done over the years to actually learn something — but I still miss being a developer . . . Thus spoke The Programmer. Read more →
Antipattern: Exactly on Schedule
I work with a company that has the following set of milestones in its standard project methodology: Vision/Scope Complete Requirements Complete Design Complete Definition Complete Build Complete Test Complete Rollout Complete I’ve noticed an interesting pattern at the weekly enterprise status meetings: a significant number of projects report being exactly on schedule for each milestone — not one single day ahead or behind! — until they get to rollout, at which point they suddenly go several months late. Some things can be faked and some things can’t. As long as you have milestones that can be met simply by declaring them done, or by signing off on a document, you can always hit them on time. But when it comes to putting actual working software in front of a customer, that’s when you really have to deliver the goods, and that’s when the milestones start getting missed. This is a… Read more →
What I (Re-)Learned Today
An ironclad but widely ignored law of software development — you could probably substitute “product development” as well: Customers never understand how something is going to work until they see it in action. Thus spoke The Programmer. Read more →
Hitting a Moving Target
IT has got to be the world’s most unprofessional profession . . . I’m sitting through a dry run of a presentation for our CEO, explaining why the company’s flagship IT project has taken so long and cost so much, with no end in sight. It seems that, compared with two years ago when the project started, headcount is up 60 percent, sales volume has more than doubled, the product mix has changed significantly, as a result of of which, requirements and assumptions have had to be constantly changed. Of course! Two years ago, who could have anticipated that the business might look a lot different two years down the road? If you said “Uh, pretty much anybody,” you’re right. Thus spoke The Programmer. Read more →
Something I Learned Today
When you’re meeting with the people responsible for a company’s software development process being the way it is, any suggestion that it could be improved is going to be a tough sell. Prepare to hear something like this: “We didn’t get where we are today by doing things wrong.” Thus spoke The Programmer. Read more →
How Long Should it Take to Define a Project?
Project X hit a milestone called Vision/Scope seven months ago, 99 days late. It’s 312 days late on the current milestone, which is called Definition. To date, the project has consumed 36,000 labor hours — 18 person-years — and $2.5 million. At this morning’s enterprise-level status meeting, it was decided that Project X will be put on indefinite hold, as it is no longer a strategic priority. This reminded me a lot of an article I read a few days ago: What the waterfall does well is to keep useless projects from resulting in useless code that needs to be maintained. I’m not sure if that’s the real purpose, but it’s certainly a great side benefit. It may sound inefficient to pay a lot of engineers to get started on projects, do a bunch of analysis and design, and finally abandon the whole thing when something else becomes a higher… Read more →
Standard Methods = Standard Results
This is an excerpt from a job posting for a Sr. IT Project Manager: Develop project plans and ensure that deadlines are met on time and projects are delivered within budget constraints. You will use standard project management tools to define requirements and track project status. Manage and prioritize projects for the division using standard project planning methods and software through all phases of the project/development lifecycle. OK, let me get this straight: You want projects delivered on time and within budget — you don’t mention whether or not you want the software to actually work, but I assume you do — and you want it done with standard tools and standard methods. It may have escaped your attention, but that is not a standard result. The standard IT project is either late or over budget or fails to meet customer expectations, or all three. If it were possible to… Read more →
Practices vs. Accomplishments
Per our Head of Software Development, IT managers are henceforth being evaluated on the “quality” of their status reports. A little background on this: We have a weekly conference call during which managers report project status. Every week you the hear the same things over and over: We’re waiting on this. We’re waiting on that. We’re working on requirements. We’re figuring out the architecture. We’re doing the design. Very rarely does anyone say, “We delivered working software to a customer.” Even more rarely does anyone say, “We delivered working software to a customer, the customer is using it, and can’t stop raving about how great it is.” What would be our motivation for evaluating practices rather than accomplishments? When I do projects, I like to be evaluated on one thing: my ability to deliver business value to a customer. Everything else is waste. Thus spoke The Programmer. Read more →
Profiles in Management: The Liar
My boss’s boss resigned yesterday. If I had to sum him up in one sentence, I would say — and I think he would take this as a compliment — that he made Machiavelli look like a goddamn amateur . . . Thus spoke The Programmer. Read more →
Requirements are Boring
You’re working on the requirements for Project X? Boring. You’ve got someone figuring out architecture for Project Y? Boring. The guys are designing Project Z? Boring. . . . Who has built something that their customer will certify is part of what they want? That’s interesting. Who has shipped something to their customer and the customer is using it? That’s very interesting. — Ron Jeffries Read more →
We Don’t Have the Money, So We Have to Think
We don’t have the money, so we have to think. — Ernest Rutherford Ernest Rutherford was an illustrious scientist — the 1908 Nobel Laureate in Chemistry, and the father of nuclear physics. His humble upbringing as the fourth in a family of 12 children in rural New Zealand influenced his approach to science, as summarized in the above quote. A recruiter called me today about a job managing an $80 million IT project. How in the world can you spend $80 million on an IT project?! I could put your company logo on Mars for $80 million. Most of the big, expensive IT projects that I’m familiar with, there really was no reason for them to take so long or cost so much. A lot of time and money could have been saved with some upfront thinking. I get a lot of this now — recruiters asking me if I… Read more →