Posted On: Tuesday, 31 October 2006 by Rajiv Popat

When I first came across Microsoft development Platforms, in the QuickBasic days, I was hooked. Because the tools allowed me to produce results. Single handedly. In a short span of time. I could write proto-types and see things happening.

Even today, my reasons for sticking to Microsoft tools and technologies (and trying to bring developers from the "other side" over to Microsoft tools and technologies :)) remains the same - Productivity.

A couple of days-to-a-week and I can cook up POCs that convey the fundamental vision of a huge module to everyone involved. We can have brain-storming sessions, take notes. They don't like what they see? I can move big chunks around and give them something they want in a matter of hours!

Whiteboard meetings / Conference calls > light weight documentation > quick releases (every month or so) > Feedback (cycle). That's how most Microsoft Developers (me included) love working.

A few days ago, an ex-army officer who is now a HR person in a software development firm, wanted some help on how to do Business Analysis asked for my help. He wanted me to review the detailed Use-Case Documents he had written for an internal project that he was analyzing for his company.

This was his First Attempt at Business Analysis and he had already prepared:

  1. Lengthy Use-Case documents.
  2. Visio Wire-frames that were as detailed as capturing widget level validation!
  3. Detailed Visio Flow Diagrams.

He was a smart individual taking his first steps towards Business Analysis and has asked for genuine advice. It was time to take a pause and have a little bit of discussion. My sole objective was to convince him about a few things:

  1. Writing complicated documents and making complicated diagrams, has nothing to do with "Business Analysis".
  2. Business Analysis is no different then rest of Software Development, where Occam's Razor and Kiss are the only two principals that work. Not Waterfall.
  3. Knowing what you are doing is more important than making really complicated diagrams on what you are doing.
  4. Use simple tools. (Unless of-course, in very rare situations, when you have to use complicated ones!)
  5. The best Analysis and Design tools ever are White boards, PostIt Notes and the Human Brain! :)

Steeve Yegge is his long Rant about agile says:

"Most great software developers around the world don't use Agile. They just work hard, they stay lightweight, and they ship great stuff. Most developers still have no idea what Agile even is. Think of that!"

It's interesting to know that even something as light and flexible as Agile doesn't sound light enough to Steeve. I wonder what he would have to say about Waterfall, RUP and writing a detailed 12 page Login Use-Case document :) Anyways, I digress. On a serious note however, isn't the same statement valid, in practically anything you do in life, including Business Analysis?

Being lightweight in a Software Development firm like wearing casuals at work. In a more mature organization / teams / work-cultures they'll understand. In lesser mature ones - they'll look at you with knitted eye-brows when you walk into office with that black T-shirt and Blue jeans. But that's OK. As long as you keep shipping quality builds on time.

I've always believed in putting some thought into what you're building before you start building it. But, I was never quite a Use-Case document guy myself. So what do I feel about some other techniques of documenting requirements:

  1. White board diagrams? - Definitely!
  2. User stories? - Sure, as long as they don't go more than a couple of paragraph each.
  3. HTML Mockups? - Sure! (As long as someone else makes them based on white board diagrams :)).

Scott W. Ambler makes an interesting point:

"The longer your project team goes without the concrete feedback of working software, the greater the danger that you're modeling things that don't reflect what your stakeholders truly need"

I've heard of projects, in so called Huge Indian Software Consultancy firms, where there are specialized teams for synchronizing Use-Cases with code, Specialized guys for just filing bugs (These are guys who file bugs NOT find them!) and specialized guys for Formatting these Use-Case documents and versioning them. I've heard stories of projects failing in these environments from friends and I am told that when they do fail it's a very ugly process basically focused towards: "We have the documentation and the proof! Let's track down the culprit!"

A friend who works in one such Large Indian Software Development Firm describes their check-in process:

"We're not allowed to check-in code or fire builds. We check-in to a different source control and email the Build Manager. Who reviews our changes and commits them to a QA source control system. A Business Analyst runs those changes and verifies that they confirm to his Use-Cases. Then the tester runs Test-Cases, which are built based on Use-Case documents and does manual testing after which the Build Manager checks our changes into the Primary Source Control System which only he has access to. All changes including caption changes of labels go through this process. We build based on Requirements that have been analyzed carefully!"

I had to quote him on this one. It's been weeks since that discussion with him and even though the words aren't exact, but the idea is precisely that.

Then there are companies where people have one meeting and start writing code. A person I was interviewing explains their Process and how they Analyze Requirements and Develop software:

"Some of us use Visual Studio 2003 while some have moved to Visual Studio 2005. We are all free to choose our own IDE, frameworks and do our thing with code. We have a couple of meetings with the clients... and then we code."

Wow! Both aspects sound equally scary to me. The first one, more often than not, leading to Analysis Paralysis followed by a search-for-the-guilty phase every time something unexpected happens and the second one... let's not even talk about that. 

Walking on the middle path is difficult. You need focus, balance and a team that takes work seriously. At the end of the day, if you really think about it:

  1. Shipping regular weekly builds and having Continuous Integration and letting everyone "see the status" is difficult - Sending weekly status reports in word files is easy.
  2. Shipping a fully functional POC is difficult - Making Use-Case diagrams and Flowcharts (which, most of the time, don't cover all flows) is easy.
  3. Having a white board brainstorming session with the stake holders and managing scope are difficult - Writing a 26 page Use-Case document that confuses your client is easy.

Didn't we all come here because we wanted simplify and get the difficult stuff right? Analyze this! And btw, please don't write a detailed lengthy Use-Case document on this Post! :)

Comment Section

Comments are closed.