Category Archives: Engineering, Not Overloading

Effective means to increase the control of your projects without increasing your risk.

Murphy’s Dictionary

Posted on by
Reply

What would you get if you married Ambrose Bierce’s Devil’s Dictionary…

CYNIC, n.

A blackguard whose faulty vision sees things as they are, not as they ought to be. Hence the custom among the Scythians of plucking out a cynic’s eyes to improve his vision.

…with the engineering adage Murphy’s Law…

If there’s more than one possible outcome of a job or task, and one of those outcomes will result in disaster or an undesirable consequence, then somebody will do it that way.

…?

Murphy’s Dictionary: an ongoing series of definitions of what words really mean on a typical development project.

Code Is Not Enough

Posted on by
Reply

So you’re a coding ace. You know the latest languages. You use the latest tools. You even write your own tools, so your development environment practically reads your mind. You eat, sleep, and breathe code.

So why do you keep missing your deadlines? Code is not enough.

You love to code. You can hardly believe that people pay you to “work” at a hobby you often do for no pay at all. You’re never without a few personal projects under development.

So why do you feel so stressed at work? Code is not enough.

Code may be the fun part of programming, but it’s only a small part of the development process. It’s not enough to see you through a tough project. It’s not enough to help you develop business and meet requirements. It’s not enough to make your project a success.

Code is not enough. And in these essays, I’ll discuss the rest of the development process.

Project metrics they never taught you in Project Manager training

Posted on by
Reply

Project management involves lots of metrics: data you gather, measure, and analyze to assess and predict the state of your project. But I find some of the most useful project metrics are often overlooked. Here are a few to add to your toolbox.

WSR (Work-to-Sleep Ratio)

This is a measure of how likely your team members are to make mistakes at crucial moments. If their WSR for the week is 1 or less, they’re probably bored. 1.25 or even 1.5 are signs of a team moving at a good pace. Higher than that, though, can be a problem. 2 is about the limit for a typical team member, and they probably can’t keep that up. Rare individuals can maintain a WSR of 3 for a time.
At one point last year, my WSR was 7.5. That’s just not good.

DODO (Days On per Day Off)

Often correlates with the WSR, and serves as another measure for the likelihood of mistakes. 2.5 is a normal work week; but honestly, how many of you work normal work weeks? 6 is a common work week for projects in a crunch. A monthly average of 13 or more is a sign that your team members may soon be tied up in family counseling or divorce court.

HBT (Handbasket Temperature)

“It’s getting kinda warm in this handbasket. I wonder where we’re going in it?” Although this can be hard to measure, your team members probably have opinions on what the HBT is. If they all think it’s getting hot, maybe you need to ask where your project’s going.

GALB (Going-Away-Lunch Budget)

Every team has transitions. That’s normal. But watch your budget for going-away lunches. If it starts to grow, that’s because the rats are deserting the sinking shipthe team members find other opportunities more appealing.

Related to this is GAAB: the Going-Away-Alcohol Budget. If your team has some drinks at the going-away lunch, that could simply be because it gives them an excuse to drink during the day. But if the bar bill starts to exceed the food bill, it’s probably because the ones who haven’t found escape hatchesnew opportunities yet are drowning their sorrowscelebrating the good fortune of their former coworkers.

Dilbert Barometer

Credit for this one goes to Scott Adams, creator of Dilbert. (Well, OK, he’ll take cash or check, too.)

As Mr. Adams explained in an email I lost sometime last century, the Dilbert Barometer is a rather non-linear scale, where both extremes are bad.

If the programmers are papering their cubicles with old Dilbert strips, that’s a sign that they’re troubled. Even worse is when they don’t just put up any old strips, only selected strips that happen to reflect what’s going on in your organization. That means they’re making judgments and a statement about the pointy-haired bosses at your company. (At one time, three walls of my cubicle at one job were Dilbert strips from top to bottom.)

But if there are no Dilbert strips anywhere, that means your organization is a rigid, humorless police state. All the people with talent and ambition (and humor) will leave. All that will be left will be those who have Abandoned All Hope. And since hope is the primary energy source for many projects, that’s not a good thing.

A healthy Dilbert Barometer measures somewhere from one to ten Dilbert strips per team member. (Mr. Adams would be glad to sell them to you.) It’s also healthy if the team members have scratched out the names in the strips and written in the names of their coworkers. That shows your team knows how to laugh. And that leads us to…

The Laugh Meter

Productive, successful teams are happy. They form a bond of shared experiences. They take time out to share ideas. They laugh.

Worried, stressed teams are unhappy. Their humor ranges from grim to none. They only talk about work, and mostly about problems. If you don’t hear a few good laughs in a typical work day, your people have lost the energy they’ll need to get through the project.

On the other hand, if your people giggle uncontrollably with little or no provocation, check their WSR. When it gets up to 3 or so, uncontrollable fits of laughter are a common symptom.

And-every-single-one-of-them-is-right!

Posted on by
Reply

So one time, I showed a friend a Web site for a project I was working on. And he asked an interesting question:

Well, you’re design guy right? Shouldn’t you be writing a design document?

And what I suddenly realized was unclear was that the Web site was a design document. It was just a design document of a very different sort. It was basically a step one design document, serving as a way to put the ideas in a concrete form for discussion. The team kinda knew what the product should do, but not every last detail yet. Some team members were ready to jump in and start coding right away, and just call it Agile Development if we needed to justify the work. Instead we said, “Wait a minute. We have a vision, but no details. If we don’t explore what some of the users will demand from the system, we won’t design the architecture to accommodate them properly. So before we can write a line of code, we need to explore what a range of users need. Then we can design an extensible architecture that should support most of those needs. And then we can jump in and start coding.” So the Web site was, in part, a format for exploring what different sorts of users would want, by telling stories of how they would use the system. And since the system was intended to be marketed to users who could use those same stories as a way to envision using the system themselves, it made sense to document those stories in a marketing-oriented Web site. But marketing-oriented or not, the Web site still served a purpose as a design document.
Now my friend would never be so rigid and unimaginative as to say that the Web site wasn’t a design document; but I have met people who are so wedded to hidebound procedures that they would have argued exactly that, just because it didn’t conform to some formally defined design document template or fit into some formally defined design methodology. And that reminded me of Kipling:

“There are nine and sixty ways of constructing tribal lays,
“And-every-single-one-of-them-is-right!”

Design is a heuristic problem, meaning that there are techniques that can lead to a solution, but no single guaranteed and inviolable path to a solution. Quoting from Wikipedia:

In computer science, a heuristic is a technique designed to solve a problem that ignores whether the solution can be proven to be correct, but which usually produces a good solution or solves a simpler problem that contains or intersects with the solution of the more complex problem.

Note the word “usually” in that description. Some heuristics are better than others, but none can be proven to be right, especially not in the general case.
There are many ways to design, because design is really just a means of communicating and refining your ideas. Different people communicate better in different fashions. Some people are more visual, and some or more verbal. Some are more instinctive, and some are more methodical. Some are more detailed, and some have a broader view. And so there’s no one right way to communicate a design to other team members and stakeholders. The only “right” approach is multiple approaches, to ensure that you cover the same material in different ways to gain different perspectives.
As an example, some people love written design docs, and just can’t see any benefit in design diagrams. Others believe in making excruciatingly detailed UML diagrams, and sometimes see those as “complete” designs. Now I’m pretty fanatical about using UML for my designs; but when I teach UML, I always point out that neither text nor pictures is sufficient. You need both. Different people and different teams will emphasize one over the other, but you need both.
That doesn’t mean that there aren’t better ways and worse ways to design. I would never consider a marketing-oriented Web site to be a complete design, just a step in building the design. But when we built that Web site, we were definitely participating in a design effort. Because…

“There are nine and sixty ways of constructing tribal lays,
“And-every-single-one-of-them-is-right!”

Where’d You Get Those Pretty Pictures, UML Guy?

Posted on by
Reply

They are pretty, aren’t they?

Layers

MissionPlanner

MissionComponents

I draw many of my production diagrams these days with Enterprise Architect from Sparx Systems. I also like Visual Studio Team System, with its tight integration with process tools. I find that to be top-notch; but Enterprise Architect is my second-favorite UML tool. It’s incredibly powerful and full-featured, especially at the low price of $199 a seat!

EA is the primary UML tool I use in my consulting work, and I often persuade my clients to purchase it as well. It’s also the tool I use when I given UML talks. And although I teach my one-day UML class with just pen and paper to keep things simple, I teach the students to use EA in my longer classes. I have them install the trial version; but by the end of the week, they usually decide to buy it. It’s that good, and I show them how to get productive use of it quickly.

Absolutely! (Not!)

Posted on by
Reply

There are only two words you should never believe: “only” and “never”.

Oh, and “always”. And “every”, “each”, “none”…Yeah, that’s more than two. You didn’t believe “only”, did you? Never do that!

Only and Always

Whenever the stakeholders tell you an absolute, don’t believe them. Challenge them on it. Make them prove it. Make them defend it. Make them put it in writing.

Or if it’s not the right time to be challenging them, make a note of it; and then later, come back and challenge them and make them defend it and prove it and put it in writing.

To programmers, absolutes like these are mathematical statements:

  • Only == 1 (or 2, or whatever follows “Only”)
  • Never == 0
  • Always == 1..*
  • Every == 1..*
  • Each == 1..*
  • None == 0

And so on. But to stakeholders, as my buddy Curtis Gray says, absolutes are figures of speech, meaning “mostly” or “seldom” or “as far as I can recall”.

So developers need to nail down these assumptions. Probe and question to determine whether these are really absolutes, or only general rules. Assuming that they’re absolutes can be a major cause of unforeseen bugs. “But they told us they would never do that!” Well, they did it. The code’s broken. Everyone’s unhappy. All because you weren’t just a little more persistent during the requirements analysis stage.

In terms of UML, this commonly comes into play with multiplicity, the range of possible participants in a relationship. This can be stated as a number, a set of numbers, a range of numbers, or any combination of the above; but most commonly, you’ll see:

  • 0..1
  • 1
  • *
  • 0..*
  • 1..*

In UML-speak, * stands for what mathematicians and others have commonly called n: an unspecified quantity. So if a publisher, for example, tells me that a book has 1 or more chapters and some number of authors, each of whom may be an author of multiple books, I’ll draw this picture:

Book (Version 1)

But I won’t stop there. I’ll use this diagram to start asking questions, and responding to answers:

  • Does a book ever have zero authors? No. Even if it’s just a compendium, we list the compiler as an author. OK, then let’s be explicit: it’s 1..* authors, because there’s never 0.
  • Does an author ever have zero books? Yes, because these are our published books. Some of the authors we work with, haven’t published yet. OK, then let’s be explicit: it’s 0..* books, because there’s a chance of 0.
  • Can a chapter ever be in more than 1 book? Wellllll… Yes, and no. Sometimes we make a combined volume out of two previous volumes, and the chapter then appears twice. So do you consider that the same chapter in two books, or two identical chapters? Oh, no, they’re not identical. We usually do some clean-up and additions on these combined volumes, to entice people who have the originals. Ah, if they’re not even identical, then they’re definitely two chapters, not one chapter in two books? Yep. OK, let’s leave that at 1.
  • Can a book ever have 0 chapters? No, of course not. Are you sure? What about a book without any formal chapter structure? We still organize that as a single chapter. What about a book where you haven’t received any chapters from the authors yet? Oh, wait a minute, you said these were only published books. That’s right. OK, then we’ll leave this at 1..*.

Then I would redraw the picture just slightly to reflect what I learned:

Book2

I would use the diagram both to capture information and to promote further conversation. Never just draw what you “know”. And never accept an absolute at face value!