Handling Fuzzy Requirements

I had a great conversation with remi Taylor of OpenRain Software today on how to handle fuzzy requirements when the customer isn’t available. You’ve been there… you get an issue tracking ticket like “Add Foozle Support” only to find no explanation of what this means other than the issue title. The customer/decision maker decided to add this ticket as your number one priority 2 minutes before getting on a space shuttle to Jupiter and is unavailable for clarification clear through next month. The customer says it’s the top priority, though, so you’ve got to do something.

The problem is an unaddressed gap in requirements between concept and action. In the customers mind, the concept may be clear. They may have a mental concept of what a Foozle is, what it means to the business, and how it will interact with the rest of the system. They may even have a GUI mockup laid out in mental Photoshop securely filed into the right hemisphere of their gray matter. As the developer, however, you don’t know any of this, and cannot act until you’ve figured out what the fooz you’re supposed to do.

The temptation in this situation is to pick up the keyboard and start coding according to your best guess of what the customer should have explicitly specified, since it’s not possible to reach him/her and you have to deliver something before they return. So you add a “foozles” table to the database, create some forms, tie it into the search algorithm and write a robust suite of regression tests. You are now the de facto project expert on Foozle and Foozle-related issues, and are pretty freakin’ proud of your work. The milestones completes, Foozle support hits production and it’s all good.

The customer returns from Jupiter delighted to find their feature request ticket resolved as successfully completed. They check out the work, and gaze wide-eyed upon the screen. Squinty eyes and an emoticon-like frowny face ensue, and all hell breaks loose. Sound familiar?

Yes: there has been a clear and obvious failure in process and communication. You–the developer–probably even muttered this when the issue hit your inbox, but let’s just assume that this particular real-world situation meant that the “proper” process wasn’t followed for legitimate reasons and you certainly weren’t about to twiddle your thumbs for two months waiting to meet with the customer upon return. Fail? Yes. The customers fault for hit-and-run management? Probably. But could you have handled the situation better? Yes! Let’s look at what could have happened to make an unfortunate situation a little sunnier…

When you first started thinking about the issue, you made the same mistake as the customer: you jumped from concept to a mental action plan without communicating the assumptions under which you made it. You formed your own mental concept of what a Foozle is, what it means to the business, how it will interact with the rest of the system, and created your own mental mockup. Unfortunately, all your concepts and conclusions ended up being completely different from the customers (since you couldn’t discuss them), and none of these discrepancies were discovered until delivery.

For our purposes, the interesting part about the situation is not that the lack of clear requirements prevented delivery of the “correct” system (according to the customer), but that you did not state your mental assumptions about Foozles  because your instincts told you it was a pointless exercise. The customer was on Jupiter and couldn’t possibly respond on time, so why bother? …right? Quite the contrary!

It is critically important to document assumptions on unclear requirement–especially when the customer is absent–because it places accountability of correct feature development back on the customer. What if your first reaction to the situation was to add a comment to the issue like this?…

I’m going to accept and attempt this issue, but I can’t find any detailed information on what needs to happen and REALLY need some customer time (~1-2 hours) so I know I’m going in the right direction. Not having this information leaves me with a LOT of fuzziness on what the expectation are, so here’s what I’m going to do…

[Explanation of your approach to the problem, explicitly making and stating assumptions as necessary in lieu of clear customer requirements. If you need a definitive answer that you can’t get, explicitly define one as an assumption so the reader knows how you’re getting from high-level concepts to lower-level action.]

If any of this is incorrect, PLEASE ping me IMMEDIATELY. I’m going to start development soon and want to definitively understand the intent of this ticket to avoid wasting time!

Your assumptions could be wrong. Really wrong. They could be so wrong that you’ve wasted 100% of your time because the customer made a typo and meant “Woozle”, not “Foozle”. The key difference is that you’ve been proactive in specifying missing requirements and gave the customer a non-confrontational opportunity to clarify their intention so you can Get It Done Right. Your clear, wrong assumption statements on Foozle concepts should–if the client was fulfilling their obligation–have triggered an immediately phone call from the customer. It didn’t, and that sucks, but given a tricky situation you’ve done pretty much everything you can do to assure the system is correct (short of a high-speed intergalactic chase to flag down the customer), and of that you can be proud.

In the best case, someone familiar with Foolze semantics will chime in to represent the customer until they return. In the worst case, the angry customer call will at least go much better since you can point to your desperate pleas for clarification on specific items, timestamped in a timeline manner before any of the “wrong” work was done.

Identifying Senior Software Engineers: Six Critical Differences

For HR and legal purposes, most development companies classify Software Engineers into ranks from I to IV (or V). The higher the rank, the higher the responsibilities, expectations, independence and pay grade. To cut it as an interviewer and manager, you’ll need to classify people accurately with a minimum amount of direct personal exposure: a non-ideal but practical requirement of most hiring processes.

While we don’t regularly use titles at OpenRain, we nevertheless have to distinguish senior talent. The core issue is, “How do you objectively identify ‘senior’ engineering qualities?” Today we’ll focus on several key factors always present in quality engineers, independant of language and platform.

Instinct

He/She has developed extraordinary technical relevance filtering to the point of being able to scroll through a never-before-seen 500 line file in a language they don’t know, and tell you..

  • how complicated the code is.
  • where potential bugs are.

Even with no formal knowledge of code smells or design patterns, a senior developer can sense ugly code and architecture from a mile away even if they don’t yet know exactly why.

Foresight

Long-term implications are always on the mind of the Senior Software Engineer. They’ve been through the end-to-end development process (from requirements gathering to product maintenance and end-of-life) numerous times, know what issues are going to arise and will point out a suitable solution long before the symptoms start to appear. (This quality thus becomes most apparent after delivery when work is bombarded with never-before-seen use cases.) The truly elite developer is often hard to identify because they’re solving the important issues before anyone else notices the problem. (Ben is a primary example of this extraordinary perceptiveness.)

Results Focus

Knowledge without application leads to arrogance without insight. Senior developers are always focused on results which stand the test of time and can easily see through posers who fluff their way through status meetings.

Communication

New developers seldom understand the required differences of communication between different types of stakeholders. Newbies tend to treat all stakeholders as authoritative figures, and are quick to lose direction when exposed to people with differing incentives.  The criticality of non-verbal developer communication is also apparent to the senior engineer.  For example, a green engineer may see issue tracking as micro-management, automated testing as an ideological obsession, and project planning as administrative overhead, but these are all monumentally important aspects required to keep all developers and stakeholders in a real-time communications loop, since many do not directly interact. A senior engineer will see these concepts as empowering and often get grouchy when not present, because not having clear priorities and documentation introduces roadblocks to results.

Time & Priority Management

A senior engineer can more-or-less tell you what their schedule looks like a week out, even if it’s not written down, and won’t be hesitant to express any issues with workload ahead of time.

Estimation

New software engineers seem to invariably produce time estimates magnitudes off from reasonable numbers. The issue largely appears to be one of Foresight since accurate estimates are oft best produced by benchmarking current requirements against past similar project experiences: a task more easily accomplished with experience. This issue is an arguing point against the “Customer is Always Available” aspect of eXtreme Programming since a green developer is generally more likely to over-commit to a workload than a senior.