EppsNet

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.

1. 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.

2. 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 out that the system is a failure until we’ve already invested the entire cost of building it, thus the rich history of big-ticket IT failures, where huge sums of money were spent and nothing usable was ever delivered.

IMO, you can use a design-code-test V model, but you have to use it iteratively every week or two weeks or at most every month on a project to avoid these problems and make sure users are getting what they want.

Thus spoke The Programmer.

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.

It’s done but we’re still working on a few things.

Then it’s not done, is it?

It mostly works, but it still needs a lot of testing.

How do you know it mostly works if it still needs a lot of testing? Isn’t that what testing is for — to figure out if it works?

I’m not making these up, by the way . . .

More of my customers have been asking me how to use agile processes, particularly Scrum, to help them manage offshore development. Since offshore development undercuts many of the practices that promote agile productivity, I ask them why they don’t just increase the productivity of their teams by thoroughly introducing agility? It seems that offshore development, with its potential for lower unit costs (dollars per programmer day), offers management hope that their losses can be reduced. Since the project is probably going to fail anyway, let’s minimize our losses by lowering our investment by using lower priced resources. A more optimistic, agile, way of looking at this problem is to fix the problem at home and increase the probability of success.

— Ken Schwaber

The last place I worked, I kept my James D. Watson bobblehead on a cubicle divider, next to a Spongebob bobblehead that belonged to a colleague.

Everyone who saw these two guys recognized Spongebob, but not one person ever recognized James D. Watson.

I mean, they knew it was someone named James D. Watson because his name is right there on the base, but despite the fact that he’s holding a double helix structure, nobody recognized him as James D. Watson, Nobel Laureate and co-discoverer of the structure of the DNA molecule.

(Ironically, one of the main reasons I got into software development was the opportunity to work with smart, educated people.)

I brought Watson with me to the place I work now, but unfortunately I accidentally knocked him off a credenza one morning and his head broke off. I tried a couple of times to glue it back on but it didn’t take. So I had to throw him away.

The real James D. Watson is actually still alive at age 80.

Someone left a box of Nerds on a cubicle wall in the IT department. (The door in the back left is my office!)

What is that supposed to mean? We are not (just) nerds!

From Alan Shalloway:

Essence of Lean for People Doing Scrum

• Lots of concurrent tasks cause waste
• Focusing on removing delays will remove waste
• Adding value and getting feedback quickly is important
• If you make a mistake and don’t attend to why you made the mistake, it will likely repeat itself
• Minimizing work in process (WIP) is a way of improving efficiency and minimizing risk

There’s a guy at work who tells me he’s the best IT customer in the organization.

When I ask him why he’s the best IT customer, he says it’s because he understands that we in IT are very busy so he doesn’t bug us too much.

That’s funny because the person I think is our best customer is just the opposite — she knows what she wants, and she doesn’t mind being difficult if it leads to better results.

Yes we’re busy, but we’re trying to do this stuff as well as we can do it and it helps to get a sense from the customer that the work is important and that doing it well is worthwhile.

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 The Programmer.

Here are 38 tips from the designer of the C++ programming language.

These in particular jumped out at me:

[5] Don’t try technological fixes for sociological problems
[8] Design processes to encourage feedback
[9] Don’t confuse activity for progress
[10] Don’t generalize beyond what is needed, what you have direct experience with, and what can be tested
[19] Use existing systems as models, as inspiration, and as starting points
[22] Design for change, focusing on flexibility, extensibility, portability, and reuse
[27] Keep it small. Don’t add features “just in case”
[29] Repeatedly review and refine both the design and the implementation
[31] Experiment, analyse, and test as early as possible and as often as possible

There is no accountability without volition, you’ve noticed, right? You can’t go “You got to ship that by November 1st and I am holding you accountable.” It doesn’t work that way.

You can’t hold someone else accountable, you’ve got to hold yourself accountable. It’s just like you can’t motivate someone else; you got to motivate yourself. And the more that you motivate people and hold them accountable, the more infantile they become.

— Jim McCarthy

I use charts like this one to track open project tickets, color-coded by priority.

At a meeting last week, I pointed out that the number of open tickets on this particular project had peaked out at 70 and was now dropping faster than the value of my house, at which one of the attendees laughed more enthusiastically than I thought was necessary.

“Why is that funny?” I asked. I mean, it was supposed to be a little funny, but not laugh-out-loud funny.

“I’ve been there,” she said.

When Gallant has a question for someone, he walks down the hall and asks it.

Goofus keeps fruitless email threads going for weeks.

Here’s an excerpt from the comment thread on a trouble ticket regarding a database record with an incorrect status code.

comment 7563 posted by goofus on 2008-09-10 8:53 AM
I did change the status code in test and this did fix the problem. However, we need to speak with JS regarding this issue as to how this will be affected in production.

comment 7611 posted by me on 2008-09-12 9:15 AM
Let's get JS's response so we can close this.

comment 7621 posted by goofus on 2008-09-12 9:52 AM
Emailed JS regarding this issue. Waiting on a response.

comment 7637 posted by goofus on 2008-09-12 2:49 PM
JS is out of the office until Tuesday, 9/16.

comment 7773 posted by goofus on 2008-09-18 2:05 PM
Sent another email to JS regarding this issue.

comment 7794 posted by me on 2008-09-18 3:30 PM
You may want to consider walking over and talking to her.

comment 7800 posted by goofus on 2008-09-18 3:47 PM
Received a return email from JS and now will be working with MS on this issue. Sent her an email for her input.

When you’re doing programming, you have to explain something to a computer, which is dumb. When you’re writing a document for a human being to understand, the human being will look at it and nod his head and say, “Yeah, this makes sense.” But there are all kinds of ambiguities and vagueness that you don’t realize until you try to put it into a computer. Then all of a sudden, almost every five minutes as you’re writing the code, a question comes up that wasn’t addressed in the specification. “What if this combination occurs?” It just didn’t occur to the person writing the design specification. When you’re faced with doing the implementation, a person who has been delegated the job of working from a design would have to say, “Well, hmm, I don’t know what the designer meant by this.”

It’s so hard to do the design unless you’re faced with the low-level aspects of it, explaining it to a machine instead of to another person.

— Donald Knuth, Communications of the ACM 58, 8 (Aug. 2008)

If you need to explain something, try mocking it up and prototyping it rather than writing a longwinded document. An actual interface or prototype is on its way to becoming a real product. A piece of paper, on the other hand, is only on its way to the garbage can.

— Getting Real, 37Signals

Q: What do you perceive as the greatest current challenge for software development managers and how do you help them overcome it?

The greatest current (and past and future) challenge for software development managers, and for all humans everywhere I suspect, is accurately perceiving reality and effectively accounting for it in their behavior. . . .

 

Q: What is your number one software project management tip, trick or technique?

Discussion should be illegal. Less talk, more code.

— PM Interviews: Jim McCarthy

In the end it doesn’t matter what names you use for your processes, good people will do good work and continuously improve what they do. So much of the discussion around Lean versus Scrum (etc.) is about marketing hype, selling consulting and training services, and cornering the market with new name-brands. . . .

Scrum is not a methodology, it is not a process. It is a simple framework underpinned by some common sense principles. Scrum offers individuals and organizations the opportunity to continuously improve the way they work. It provides a space for people to behave like human beings, with trust, respect and passion. That’s about it. But that is huge.

— Tobias Mayer

Agile development isn’t a thing you do, it’s an attitude, it’s a set of personal values about responding to the real world, being open to the information that is there and being willing to do something about it.

— Kent Beck

You begin by stating that agile is basically three things: a set of engineering best practices that allow for rapid delivery of high-quality software, a project management process that encourages frequent inspection and adaptation, and a leadership philosophy that encourages team work and accountability.

You go on to say that success in today’s economy requires us to respond quickly to changing market conditions. Agile processes allow our teams to meet the changing demands of their customers while creating environments where top developers want to work.

— Agile Chronicles: “The Agile Elevator Speech”

The most common verb associated with requirements is “gather.” Yet most requirements that end up fulfilled in a system aren’t gathered. Yes, I know, there are always a few requirements that are so obvious in a new system that you can “gather” them from stakeholders, but gathering implies that the requirements are already out there, fully formed and fully understood, and ready for harvest. It just doesn’t work that way. No stakeholder ever says to an analyst, “Requirements? Why, yes, I have eleven requirements. Eight are functional, one is a usability requirement, and the other two are operational requirements. Are you collecting constraints now, as well? I have three of those. Please sit down, and I will elucidate perfectly clearly on each and every one in turn.” Most requirements are discovered–or invented. Many are transformed or compromised along the way.

Most stakeholders don’t consider the underlying requirements of their work; they do their work. They are not in the business of reinventing the work. The arrival of a new project is the point in time when the ideas for new possible ways of doing work force us to consider the underlying requirements. If you go to an experienced front-desk hotel employee and ask what requirements there are for the check-in process, you are most likely to hear in excruciating detail exactly how the check-in procedure works today. Indeed, you will probably hear more than just about check-in; you will hear about the reservation procedure and how it impacts the check-in procedure. It never crossed the mind of that employee to consider what information and material goods the hotel needs in order for a guest to do self check-in with a new automated system. And the idea of the guest selecting a room from all those available is a shock. It’s not done that way!

This is why we have folks with “analyst” in their titles. Analysis is never simply about recording requirements from clients and other stakeholders. Analysts are not waiters who take orders without comment. Analysts need to learn how to tease out the basic rules–the policies–of the system and liberate all stakeholders from thinking that the new system should be based on current procedures. It is invention that is at the heart of analysis, not gathering.

— Tim Lister