HL Arledge

Customer design or Too Many Cooks Sink Ships

When designers attempt to please everyone, someone always ends up angry. The key to good design is bringing all interested parties together in order to balance interests and find solutions that work for everyone.

In the early days of EnvisionConnect, customer advocates on staff shouted:

“Our users know what they need better than anyone else. Let them design the software and force the developers to deliver exactly as they define.”

Who could argue with that philosophy? The customer knows best, right?

Let’s return to the mixed metaphor of “Too many cooks sink ships,” and let me tell you a story…

There once was a shipbuilder who hired the best engineers, but he sold ships to the government and was forced by contract to design the ship according to specs put together by a government committee.

The shipbuilder ordered the designers to build every gadget and widget the government committee could dream up, and the ship that evolved from the process was beautiful!

On this ship, you didn’t have to take the stairs to go from deck to deck. Everything in the ship was put on one easily accessible deck. And all of the gadgets, widgets, bells, and whistles glistened. It was the most spectacular-looking ship the government committee had ever seen.

When war broke, the government ordered the ship launched. It would sail to the other side of the globe and squash the evil doers.

Unfortunately, the ship was too heavy. It moved too slow. By the time the ship reached the enemy, the war was over. That’s not all that bad really. If every country followed this design model, the world would be a more peaceful place.

The moral of the story is that all interested parties have to be involved in design.

Luckily for us, the world of Agile software design doesn’t work like ship building.

We do insist that users of the software design by committee on the first pass (in industry jargon, the first iteration) but then it’s up to the engineers to weigh the needs of the many against the wants of the few and refine (industry jargon again, refactor) the product into that happy medium that makes everyone happy.

This year, our customers will notice that we’re changing the way we collect customer feedback—finding ways to extract information faster without wasting customer time, and our developers are defining “the how” and restricting customers to defining “the what”. And when some “what” is ultimately detrimental to a more important “what”, it’s our job to help customers understand the trade-off they are asking to make.

Now, you know why it’s taking a while to christen EnvisionConnect 4.0.

EnvisionConnect 4.0 as she stands today is the most beautiful and the most powerful ship in the fleet, but Envision outruns her. As goals go, our next BIG target is making EnvisionConnect faster, even if it means dropping a few bells and whistles overboard.

Watch this space to see how we do.

How not to hire a developer

This is from a job posting I found on the net...

"Knowledge of agile development methodologies (e.g. SCRUM, RUP).
A BS/MS degree in Computer Science or related technical field is required...One of our guiding principles is no meetings across the team one day a week—great for heads down work and potentially where you do your best work."

This is a place I would never work.

Let's look at the problems individually...

"Knowledge of agile development methodologies (e.g. SCRUM, RUP)."

Any shop that thinks that Scrum is an acronym and that this project management tact somehow equates to the Rationale Unified Process development methodology has no idea how to succeed.

"A BS/MS degree in Computer Science is required."

This requirement has always been one of my favorites, and my perspective on the issue is likely to offend many among you.

Public appearance this week, call the assassin

An invitation for you...

Central Valley Software Partnership

presents

A two-meeting showcase of innovation
in Fresno's software development industry

Participating companies include

July 10

• Argos Software
• Decade Software
• Decipher
• WatchDoit
• Yosemite Technologies

August 14

• Famous Software
• Galaxy IT
• SJV Technology Group
• Company TBD
• Company TBD

Who Can Attend:

Anyone with an interest in the growth and well being of Fresno, California's software development industry.

No rest for the Scrum warriors

Over at Elegant Code, David Starr seems to be talking about our office...

"Scrum has finally been recognized as an excellent team management model that supports agility. It is also prone to fracturing at large scale and must be held together with more pressure at large size. It takes more than Scrum to deliver on the whole promise."

And about my team...

"Test Driven Development is a wonderfully lean practice that has genuinely matured to a standard engineering practice.

Who can argue with the constant attention to quality? Now that we can agree this is how to do business, we are simply evolving the technique rather than arguing about whether it has value.

Good stuff."

He also offers some warnings that almost applied to our teams...

"I cannot count the number of times people have represented their practices as 'Scrum-like'. I commonly ask, 'Did you start with Scrum and modify it to fit your shop?'

'No,' is the common answer. 'We read the books and picked the parts that seemed to make sense for us.' "

I laughed out loud when I read this, remembering how hard we fought off Scrumbut in the early days with my team—and more recently in our Design and Client Services teams.

However, David's warning is an important one. If we get lazy, if we start sinking back into our old processes, all of our successes could vanish in a heartbeat.

There is no rest for the Scrum warrior. One must be ever vigilant to ensure that the process machine is well oiled and humming quietly.

Thanks for the reminder, David!

Agile and Lean really Hipopalorum and Lopopahirum

In his blog this week, Martin Fowler attempts to explain away the misconceptions that "lean" and "agile" software practices are two different methodologies. I wanted to add that the idea that these were different came from consultants who are trying to convince you that the differences are so complicated that you need a consultant to succeed.

Whether your talking about Extreme Programming, Scrum, Lean, or Agile, you are really talking about tools that follow the same basic practices and understandings that make these all work.

As I explained in my guest post at Management Craft, you are talking about common sense.

Agile practices work well in Software Development, but if you boil them down to their basic common denominators, you are talking about something that can work for anyone—without consultant hand-holding.

Being a history buff, this whole Lean versus Agile debate reminds me of something Senator Huey Long used to joke about in the 1930s.

There were two patented arthritis medicines on the market, one was called Hipopalorum and the other was Lopopahirum.

One you rubbed on your body from bottom to top and the other you rubbed on your body from top to bottom. The ingredients of the product were exactly the same. They were just being promoted by different salesman.

This is not unlike the different business consultants that confront us today.

Anyway, just to finish the story...

Long—aka "the Kingfish"—had been elected Louisiana governor, then United States Senator, and he announced his candidacy for President of the United States in 1935.

Most of his speeches compared our political parties to Hipopalorum and Lopopahirum—and their product vendors.

"The only difference between the two parties is one skins us from the top down and the other skins us from the bottom up."

Huey Long was assassinated in September of 1935.

Requirements, I pondered, weak and weary...

I went. I saw. I learned. I am here to recount my experience.

Firstly, if you follow use case best practices, then you are way ahead of the game in understanding how RAVEN works. We do so at Decade Software, but instructor Steve Yeo told us that this rare among the software shops he visits.

The user-interface is modeled after Microsoft Outlook, so there was only a small learning curve. We covered the basics of the application in under two hours.

The other six were discussing those best practices.

The rules for writing Use Cases are simple:

• Write concisely—no extraneous words.
• Write in Active Voice—not passive voice.
• No assumptions—assume your reader knows nothing that you are explaining.
• Be consistent—if the system shows once, it shouldn't display later.
• Flows describe Functional Requirements Only—Preconditions, Post-conditions, and Business Rules are documented outside of the flows.
• Document all alternate flows—If this then that, otherwise that.
• Use Requirements English—Actor Function Object Target ("User enters Login Credentials in the Password Dialog.")

RavenFlow's sales folk get a little cryptic discussing pricing structure, but once you cut through that—and verify that you can live with the best practices defined above—I assure you that RAVEN can help your organization deliver requirements faster with little rework and greatly improve transparency.

But...

As Steve said...

"We can only give you the tools to get the job done. Solid processes start at the top and only work with complete buy-in from the team."

Now, where have I heard that before?

Secrets to keeping software bugs at bay

In case you missed Darryl's blog post entitled, A Bug's Life, I recommend that you review it. He does a fine job of recapping how we eradicate defects at Decade Software Company.

I remember when I first suggested that we could maintain a zero defect count. Darryl—like many of our clients—initially thought that was impossible.

It wasn't always easy, but we proved the critics wrong.

If you're working for a software company and are still plagued by defects, I recommend you step back through this blog—beginning with the links above.

Our "secrets" are all out in the open for your partaking.

There is no reason for any software company to nurture defects that are 60 or more days old.

Those who do, are just too lazy to read.

The really good stuff is hidden in the articles

My team always—at least initially—thinks my instructions or suggestions for process improvement are a little hard to follow. This is likely because I am never afraid to say...

"My last idea could have been better. Let's try this instead."

Teams hate change!

Anyway, this is a real example of hard to follow instructions...

"I said 'Never name your classes after the pattern itself.' 

But then someone pointed out 'What about Factory classes?' 

'Oh, ok, ALWAYS name classes after the pattern.' Except for Singleton or Façade, and maybe a few others. 

Ok then, NEVER name after the pattern, except when you do, sometimes, and then ALWAYS name those, unless otherwise noted."

Actually, it is a good example of what can happen if you take something out of context.

What you need is some Stack Overflow

Two of my favorite geeks have teamed up to produce a podcast.

I highly recommend that you checkout Stack Overflow, hosted by Jeff "Coding Horror" Atwood and Joel "On Software" Spolsky.

To be honest, I haven't listened yet, but considering the extensive knowledge and quirky personalities of these two computer gurus, there is no way this show won't be a winner!

Robots are coming!

According to Robots.Net and Dr. David Hanson, lifelike humanoids are just around the corner...

Sergey Popov writes, "Skilligent recently released an updated version of its computer vision system" (PDF format). He also posted a YouTube video of a robot using their software. Steven Frye writes, "Unlucky Fried Kitten has a new musical coming out soon titled The Robot's Revenge. It's about the day that Robots will inevitably take over the world.". The Swirling Brain has been busy sending me more links than I know what to do with including a NewScientistTech story on Capuchin, Stanford's climbing robot, a CNN story on Robosapient:Rebooted, a film starring the WowWee robot, a Wired story on mini-robot spy balloons, io9 stories on Surrogates, an upcoming technology-oriented Bruce Willis moving and a creepy emotional robot, an AfterDowningStreet update on the Pentagon's cyborg insect program, and an article on El-E the human interaction bot (another reader sent links to the Healthcare Robotics lab where El-E was designed). Roland Piquepaille, meanwhile, has posted new stories on firefighting beetle-bots and the 3D-R1 mine mapper mentioned Tuesday.