HL Arledge

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.

Software Quality Costing Companies Big Bucks

Yesterday, I wrote of software quality issues plaguing companies everywhere. InfoWorld Magazine published a survey related to this today.

Read Poor Software Testing Hits Companies in the Pocket.