Combination Therapy for Requirements using BDD and UML

Problem

Generally, we write requirements in use case structure. Use case structure gives us all elements required but by design , it is a vague format which are devised around use case diagrams. Every software professional has its own flavor of writing use cases. Even the sections of use case structure varies person to person.The intrinsic details of the parts of use case specially use case description, preconditions and post conditions etc] are vaguely defined. Writing use cases in clear format is also a skill and that depends upon the person who is responsible for collecting requirements.Use case are still useful in mature kind of organization but it is not so much effective way when we do not want to have upfront big designs. So dilemma here is how to collect the requirements and the new approach should be better than standard use case structures and should be fairly objective.

There is also a second angle to this use case discussion. Requirements have bigger impact on business and cost part of IT projects. Many times, due to not so clear communication between IT vendor and client over the requirements, this cost of lot of rework and hence the cost to client.From client’s viewpoint ,it is difficult to understand use case type of language and there is a chance to miss out or assume requirements/scenarios ,which becomes cost(in terms of money or time) for them afterword. Situation becomes bad in fixed cost projects. I had experienced this bitter pill many times.

Solution

So the solution I am proposing here is , Behavior Driven Development [BDD] kind of requirements collection for even the people who are not practicing BDD. From past few months,I am sort of wandering in TDD,BDD forest. Now I am going ahead with nBehave and Specflow and Gherkin which has changed whole lot of things for me on coding front.

I totally understand that BDD can’t be fully rolled out in some scenarios/in some organizations[no silver bullet!, lack of expertise, no enthusiasm to learn, cost of learning curve and transformation etc] but I am sure that, we can at least move to BDD style of requirement writing which is kind of closer to silver bullet:). See the following example. I had directly taken this example from Dan North’s blog. BTW, Dan is pioneer in BDD and I guess, he is the first who coined the term "BDD". He has also compared use case format with BDD style. Here I think, interesting angle from my side is merge both of them to take advantage from both styles of requirements collection.

In BDD, The requirements are collected in story form like:

Title (one line describing the story)

Narrative:

As a [role]

I want [feature]

So that [benefit]

Acceptance Criteria: (presented as Scenarios)

Scenario 1: Title

Given [context] And [some more context]…

When [event]

Then [outcome] And [another outcome]…

Scenario 2: …

ACTUAL EXAMPLE:

Story: Account Holder withdraws cash

As an Account Holder

I want to withdraw cash from an ATM

So that I can get money when the bank is closed

Scenario 1: Account has sufficient funds

Given the account balance is \$100 And the card is valid And the machine contains enough money

When the Account Holder requests \$20

Then the ATM should dispense \$20 And the account balance should be \$80 And the card should be returned

Scenario 2: Account has insufficient funds

Given the account balance is \$10 And the card is valid And the machine contains enough money

When the Account Holder requests \$20

Then the ATM should not dispense any money And the ATM should say there are insufficient funds And the account balance should be \$20 And the card should be returned

Scenario 3: Card has been disabled

Given the card is disabled

When the Account Holder requests \$20

Then the ATM should retain the card

And the ATM should say the card has been retained

Scenario 4: The ATM has insufficient funds

…

I think Along with story, if we have mockup/screenshot[off course with Balsamiq mockups! ] of proposed screen and control, data type range chart we used to have with our existing UML format, we can move towards clear requirements.

Benefits

This will benefit in following ways:

1. It will help to gain common understanding between client and IT Vendor,about what has been covered as requirements and what has not.
2. Client will find easy to go through requirements since requirements are written in very structured fashion and in plain English.
3. Organization wide, requirements will be captured in same fashion and we can really estimate based on stories and find how simple or complex the story is based upon no. and complexity of scenarios it had. Hence its really easy for going with statistical process control for estimation.
4. Change Requests are dealt with adding/removing/updating the feature/story/scenarios.My observation here is they only change the scenarios. In very rare cases, features or stories are changed.
5. Testing team will reap the greater benefits here since they can write these stories as per their understanding and take part in RE process in very active way like finding out the missing/not clear scenarios etc.
6. Testing team do not have to write any other test cases, This can serve as live requirements as well as test cases for them.
7. Unit Testing for Developers will be easy since now they clearly know what kind of scenarios they have to cover which is bit difficult and time consuming in Use case format.

Let me know your thoughts, specially BDD and UML experts…

Many good points are noted as what should be in story by BDD pioneer Dan north in his post (http://dannorth.net/whats-in-a-story).

It’s really refreshing for me to see the BDD light. I will cover an example of my solution and more on requirements collection thought process that I follow, in next post.

 

Share this post :

Programmer’s Bad Habits II

Continuing part I of this series, here are some more things to add to bad habits or common fallacies and traps of programmers that are holding them from performing well.

1. Carry over the dead code/experiments/comments with you.

Go to any system/project’s codebase that is more than a year old and you will get to know what this means. You see the comment that says “Sales Invoice in next five lines” and more than 20 lines of code that is commented out and another 10 lines code that are currently working as you debug…and nobody can explain what that old commented code does but they don’t dare to clean that up.

2. I can’t fix another programmer’s code, rather I will rewrite it.

Ah! This is a classic and I admit that I had been also got hold of it in my early carrier. One programmer never says good things about another programmer’s code. I think this is in our gene and sometimes even if I think of this ,I think programmers in somewhere deep down their minds wanted a perfect world and each one has their own version J of it. Anyway, what all I can suggest is they can read martin fowler’s classic ‘refactoring’ book and this notion will go away.

3. The world can be written only with “if-else” and “for” loops and method reuse.

Junior junkie who can code for days and night and fresh from colleges or worse spent one or two years in some company can write entire systems in if-else and for loops and some procedure reuse. I think some or the other way this has a root cause of “failing to unlearn what we had learned first”. Most of these guys had learned C language as their first programming language and may found they were good at it or they presume that they are good at it. Biggest mistake our schools and some local book authors has did is they are teaching procedural and object oriented programming language the same way.

These authors had not thought over the object oriented principles, rather their focus is teaching upon the tooling of object orientation like inheritance and polymorphism and unfortunately this is the case in India which has got some credibility in IT.

4. Testing is inferior to programming. It is not what true programmer’s do. Testing is THEIR (Test Engineer’s) JOB.

I spent my early years of career in small start-ups where we don’t have luxury of appointing a separate test engineer. Whatever we write, we have to make sure that we are doing it correctly and the result of it is though I have got respect for the test engineers since I realized that say after testing for basic flows and validation errors it is very difficult to think of something different that can break the system. In regard of this thought I had learned some testing basics from various websites and still those are very handy even as a programmer.

Nowadays, While working with midsized firm and continually reading about TDD all I am realizing is, programmers had a misconception that they can write a code that had errors and they can just give it to test engineer to clear even basic things like spelling mistakes.

It is shameful that people do not want to test their own code and worst of all rely on some other individual for correcting their own mistakes.

The notion of TDD is good but their also our cleaver programmer (as well as some lousy test engineers) friends tell us the list of excuses like schedule, how can I write the test when there is no development etc.

5. Code review means somebody should check their code line by line for all aspects and point out the mistakes that they had made.

Yes, it is insane but I had seen some managers and some programmers have such ridiculous expectations from code reviews. First thing is programmer should be responsible for the code he/she is writing and not the other fellow who is helping it out to make that code better.

Code reviews should be conducted on sample basis and with the help of some tools likes of static code analysis etc. Checking the mere code conventions should not be the only intent of review. It would be more beneficial that code reviewer should do some firsthand refactoring and in that process programmer would learn things and two about the code as well as this leads to better design.

6. Creating a build means compiling the code.

For the people who have not been in the agile/product development have this misconception that compiling the code is the thing that makes the build process.

These people are missing so many steps that makes build process. I even really doubt that these people consider build as a process.

Many times project requires code signing ,obfuscation of code, replacing connection strings from test environment to production environment ,building for various platforms likes of Windows,*nix or 32 bit,64 bit as well as routine tasks as zipping the release, pushing the release over ftp, emailing about the release to stakeholders etc.

The people ignorant about the build process should really search for the continuous integration and trivial toolset of it which includes brilliant TFS, cruise control, Hudson, rake, NAnt etc.

These fallacies and traps are costing our customers millions and we should recognize it. In my opinion the root cause of these is the way SME’s hiring the resources, further on lack of training and setting the culture to sub standards.

The more I go deeper, I think the waterfall thinking model is still lurking people to write bad code and managers had their fear to adopt the bottom up management approach and what we need is agile mindset and learning organization.

“Learning is not child’s play; we cannot learn without pain.”
- Aristotle

Share this post :

Programmer’s Bad Habits

“Good habits are formed; bad habits we fall into.”

There are much literature that has been written on habits or misconceptions that gets acquired by human beings and how it become hard to leave, especially if those habits or concepts are considered as bad. Bad habits as we all know, seems easy and “quick” solutions that are acquired, mostly unconsciously. But good habits are hard to acquire but gives long lasting benefits to us.

As a developers/programmers or architects, we also acquire habits/misconceptions in our work that consciously or unconsciously imposed seems “quick and easy” solutions to our programming problems. I wanted to throw some light on such bad habits of us-developers…I had also gone through some of these bad habits but thankfully dropped them in my journey to become good dev. Some people may also term them as “anti patterns”, but I am not very comfortable about the word ‘anti-pattern” ;maybe I explain my reasons of terminology in some other post, but now let’s focus on these bad habits or misconceptions.

1. Ignore the warnings, while compilation since they are not causing any problems.

I had seen this many times and I hate this. Some colleague of mine calls me up says that s/he couldn’t find the bug in their program and even after spending a couple of hours and tried all the things s/he can do…

First thing I would try is, I rebuild codebase and see if they had any compilation errors or warnings…and here we go..many warnings yelling for attention!! When questioned about the warnings, the usual answer I hear is “oh! They are not causing any problem so we just ignored them”…and when I see the warnings..Most of the unfound reasons of the bugs are lying in warnings that are in front of the programmers but they can’t see it.

I am not suggesting that you convert all those warning messages into error messages, but warnings are generally-the sign of future or runtime error places and signaling towards inefficiencies in code ;so treat them like errors and work on those.

2. If code is compiling, it is working code.

If you give some junior any requirement and say them that “ok, you need to code this feature/use case etc.” and just watch them. They just start writing the code at the blink of the eye and eager to show their worthiness. But the unfortunate part is next, and that is when they say I am done with the feature/s after their code is getting compiled. Hey Guys! Wake up… writing a compiling code is just a first step and hell…you are not done…Your code has not even passed those unit tests and how you dare to say that your are done.

3. Code once written and running should never be touched.

I generally deal with legacy not in C/C++ terms but have reengineered systems those are in VB 6, .NET 1.1, and likes.

In my opinion, legacy should be termed as “system with inefficiencies even it’s written with latest and greatest likes of .Net 3.5.” Unfortunately that is not the de-facto definition.

Most of the developers and even sometimes project managers have this nausea that if the code has written and that is running that should never be touched.

They say, hey! That is running and as per specifications, why you want to change it or make it better [they see as, this idiot is fooling us by wasting hours on thing that is already done!!] What they miss out is; it is like rusting of the iron. If the code can be improved even a bit by any means, it should be done. It is like you see a piece of rusting iron in your vehicle and still you do not do anything and run your vehicle until any accident occurs.

Damn, that kind of code can carry any characteristic like rigid to requirement changes , fragile like showing strange behavior like fixing bug in one part of code throws the strange error in some other part of the code which is not even related with first. So, the point here is ,we need to remove the inefficiencies.

4. New features can only be floated out by writing tons of new code.

This is really hard to realize that we had picked up such misconception and even harder to come out of this!!

For example, during one re-engineering project, I realized that our architecture is giving ability to product that the client can sell different modules/subsystems to the end users as on need basis and we communicated this to product owner and he liked that idea and which in turn given the product the new revenue stream.We have delivered a feature that is making a strong business sense for product owner without adding extra code!!

All this becomes possible not because we have added some more code for such business feature but cleverly re-architecting the system.

Oh! This post is somewhat getting bigger,I am sorry to break the continuum but just like ‘short methods’ is a good idiom to follow in code, I am keeping this post small and write it in chunks as a true agile developer

Till then Happy Thinking!

Hope to see you next time…

 

Share this post :

Hiring Developers

Recruitment is the most important thing in learning organization. It can change the every aspect of your organization. You hire right people with right attitude, give them chance to flourish and they can turn your SME into fast, responsive well oiled machine which is ready to adapt to any kind of business challenge. In fact I think this is so crucial that if I am the CEO then, I must have taken part into interviews of prospective hire.

Nowadays developers know all fancy and shiny things and their resumes are flooded with the buzzwords such as web 2.0, WPF,WF ;but very few have mastered the art of computer science. I think basic developer should not fall into the trap of these buzzwords and go for building the sustainable portfolio. If you are a polyglot programmer that is good thing in today’s market, but you should be really a master of at least one technology.

Many Developers try to pretend to know everything that existed in the world that might be from MS-Office [don’t laugh! I had seen such resumes where people come for senior developer post and they even mentioned MS-Office in Skill set!] to WPF and WCF.

These are really jargon driven people who just think that they are commodity stocks.

In my opinion what senior developers should possess is;they should be at least good in algorithms. Not some Google’s page rank kind of algorithms but just real ground work algorithms like searching sorting and building up stack queues will be good enough.

Second most important thing is ,they should not be so much affectionate to some language’s syntactical curry rather I dare to say that even if they can write some good pseudo code I am fine with them.

Concept Implementation and differentiation is also good area where senior developers could look at. Inheritance, polymorphism implementation in various OO languages like C++, PHP, C# or Java should be known.

Last but not the least they should possess some good hobby that they really care about. Yes, this is crucial to look at from wide angle into life and things that falls beside computer knowledge. It will surely help them to grow into a good leader or good team player.

Share this post :

Reuse should be side effect and not the goal

Last night,I had a talk with one of my friend who is also a developer at some other company,In his project,client is always looking for cutting the corners by which he could save on cost of development.

As a clever IT manager,For faster development,client’s IT manager is insisting on a design which has reusable components identified and well laid out,while my friend is collecting requirements and doing the requirement analysis. But to my surprise,my friend is also feel good about this notion.I think I am bit behaving like a pessimist here but I am somehow feeling uncomfortable because of this thought…since here they are treating the goal of system designing or architecting as reuse while ignoring the sole goal of architecture is to better serve business…to find the solution for business…

In my opinion, reuse should be side effect of your design and not the goal of your design.

Certainly reuse is a good thing to have inside your system but it should emerge rather than we impose reuse as goal on our design.It suppresses the creativity of fitting and integrating the different aspects of the system as well as it dangerously introduces the dreadful impact of looking the entire world into black and white rather enjoying the diversity and cleverly utilizing diversity as a strength of system.

The trap lies in perspective of architect or people who are designing the system since “emerged reuse” can co-op with inherent business changes that are going to come in lifetime of system while in case of “artificial or induced reuse” system can not withstand with the upcoming changes of business.This happens and I had observed it since "intended reuse" imposes "reuse" as a goal rather than just a strategy inside the system.
So the components are built with keeping today’s constraints in mind.While architect or even end users of the systems are not sure that whether today’s constraints will be there in future or will be removed.

Just on a curious note,Have you anytime observed reuse as a goal?

 

Share this post :

Why Your Agile Project Can Not Be A Success

1. You think agile is iterative waterfall.
2. Somebody from your top management told you to use “agile” methodology on your project.
3. You think Product Backlog = project plan,iteration = milestone , scrum-master = project manager,sprint retrospective = project status meeting and agile discipline = micromanagement.
4. The sales team decreased your estimates because they believe you can work faster.
5. You use same estimation techniques for waterfall and agile project.
6. Project estimates magically match the budget.
7. You have project manager on the project who is in charge of everything.
8. Every Friday, your project team work on data collection and prepare metrics for your project managers.
9. Your team do not have scrum master.
10. Scrum Master do not participate in coding and testing.
11. Your Scrum Master do not understand the acronyms DRY, YAGNI, or KISS.
12. You had all the requirements predefined in specification document and you think project will be get executed according to specification.
13. You think design activities are ,a time to fully and accurately define designs and models in great detail and programming as a simple translation of these to code.
14. You try to plan a project in great detail from start to finish.You try to speculatively predict all the iterations and what should happen in each one.
15. Your managers swear by Microsoft project.
16. Your managers haven’t read “Peopleware” and “Mythical man Month”.
17. You do not know anything about your team’s “velocity”.
18. Your project teams don’t have burn down charts.
19. You define all the architecture upfront at the start of the project.
20. You have only one iteration.
21. You think refactoring as a rework.
22. The last book read by your senior developer is “Mastering VB 6.0”.
23. Your software architect work in silos.
24. There is no or minimal feedback and adaptation;users are not continuously engaged in evaluation and feedback.
25. You think  “Test engineers”  cannot be introduced from day one of project since no code is developed.
26. Everyday your developers work until Midnight everyday.
27. You think software quality means creating some CMM compliance documents.
28. Your QA team does not know how to code.
29. Your test engineers could not code.
30. You have specialized roles on your project teams like developers,test engineers,project managers.
31. Your developers do not practice J/N Unit.
32. You see deviations from requirements or design during later steps ,as failure or concerns in not having sufficiently skillful or through.Next time,you try harder to get it right.

If despite all these odds, if somebody is claiming that their projects are successful then I have no doubt that there are some software heroes working in their organization;who might be thinking of leaving that organization

Quality Quote

Quality is a perception of receiver.

-Lalit Kale.

Balsamiq Mockups Review

Nowadays I am doing requirement gathering and analysis for a good project here in Gibraltar.So you can imagine lot of user interactions ,taking interviews of end-users , sometimes shadowing them to their specific work function and lot of questioning etc are going on…at least project started off good and we are heading in correct direction.

For successful execution of project,the team which is going to implement or code,should get understanding of the ideas and concepts and functionality and thus the need of good mock up tool arise. These tools plays a vital role of explaining the ideas and bringing the life to boring documentation. It is truly said that “1 picture is equivalent to 1000 words!”.

In my previous projects,I had mostly used visio and its sort of standard at my workplace for mockups.Though recently I had also tried out serena prototype composer for one project.These tools have their advantages and disadvantages.

Visio is the huge software.It is not meant just for prototyping or diagramming.However,it comes at a price and it requires a lot of time to starting off and be expert with it.You can find massive features are poured on as just any other Microsoft stable software.After using visio ,I came to a conclusion that visio is good tool ,but still not a very handy tool for creating mockups quickly.

I explored a bit more on internet and found Serena Prototype composer.Serena prototype composer scores over visio ,when you want a clickable prototype.But then serena prototype composer needs to be installed where you want to run your prototype and seems to be pretty rigid kind of a tool.I didn’t like it much though it has unique advantage of creating clickable prototype.

Then again in search of perfect mockup tool,I downloaded and tried many. One day(actually night),when on the verge of just concluding that there is not so much great tool other than visio,I found the gold “Balsamiq Mockups”!!!

As a practice,Without much hopes,I downloaded and installed it.As a authentic software engineer,I never use manuals or help to use software [In fact,I had reached to conclusion that if you need help or manual for running a software,there is a problem with usability of that software]. Firing up balsamiq tools,I was just kind of landed in my dreams!! Since,it is just made for making mockups!!! Very no not friendly,I will say inviting user interface.there are all UI elements at the tops with really big and wide tool strip which shows of drag and drop user elements some common like buttons,text,all types of containers(i.e. group box,tabs etc) and some uncommon like accordion,cover flow,video player,street maps etc.The most surprising is I found sticky[comments as they call it ] and charts and graphs as well.Wow! pretty genius work.Since,many business software always need this and very few people do have mockups for this stuff.

You can create a new mockup and start building your mockup by dragging and dropping these elements.When you drag and drop the vertical and horizontal guard lines appear to assist you for placing the elements,taking care of alignments which is again cool feature.

You can set properties of individual element by selecting the element and then property bar appears out of nowhere.You can drag it anywhere so that it will not disturb you or obscure the view of element that you are working with.Also The properties are fantastic set,Just as what needed no extras .These things truly live “YAGNI(You aren’t gonna Need It!!) agile principal.

On top of this,the mock up you created can be saved or imported as XML file or can be exported as PNG files.

Balsamiq Mockups team has really come up with really genius product !!

However,there is a saying that greedy man and end-user can never be satisfied 

I must also point out some things that they can improve into their next version.

After using it for two or more weeks ,I realized that grouping and un-grouping of containers and their child elements are somewhat confusing to me.Since,The controls that we drag goes back side of group box and another thing I wanted is the ability selection of many controls like visio gives. As of now,to move entire thing,we have to group them.There must be the selection ability for controls that are not grouped.

The community of Balsamiq Mockups is also good.And they had come up with several templates that you can find at http://www.mockupstogo.net .

All in all,It is insanely great tool built by genius people out their at Balsamiq.I think I can saved at least 40% of time required to create mockups with Basamiq compared to Visio.I will certainly recommend that try your hands on Balsamiq and you will be happy making your mockups ever after.

 

Share this post :

Types Of Software Companies

 

Technology i.e. science and Management are two pillars of IT shops.The main theme behind separating these two terms is because of the ways these terms shape the culture of company.

The visible attributes of the the companies which value Technology as equal as Business are their software engineers/techies are to be believed as most precious entity in the organization.These companies are trendsetter in their own chosen field of work.The designation does not matter for raising your voice in arguments and expressing contradicting views to that of your colleagues[read your bosses if you are in management stuffed company].You can be your very own in such a environment.You can practice your craziness and spit out any damn idea or coin a new funky term,the only thing that matters is how good you are in your work.
These companies are often run by media shy and only get recognized by their products or when they broke out their new innovations.

On the other hand,there are companies that value Business more than technology.In such setups,software engineers/techies are treated like commodities.These companies are mostly flourished and dominated by some kind of management degree holders.These folks believes on laying down strict sense of organizational structure.These companies are more often profit tearing companies.The way they operate is more frequently like any other manufacturing unit.You can here lot of meeting agendas and close door discussions.Employees are more often pointed to their policies and often seen having water cooler gossiping etc.These have very good frontal face as they had good PR,Marketing departments those pays heed towards media.

Think for a while and comment about Where are you working now?

Share this post :

Cost Of Not Upgrading Developer’s Computer

Many times, there is situation where people in SMB and startup businesses do not upgrade their computers and perhaps their software tools too. Most of these businesses think that it is pretty ‘OK’ to run things as it is ,for years since either they are running the same things.And upgrading systems would add up to their cost.But they eventually forget the cost of loss of productivity of developers. This added cost would certainly pain for customers as well as it can harm your business severely.

Let me give you an example,If there is some code base of your product, which takes 3 minutes to build and compile and run on normal [read upgraded or having latest hardware and software], and you had a machine with your developer which is taking 7 minutes and project would gone up to 24weeks and developer had generally compiled solution even only 50 times per week then you are losing the productive time of 2 Person-Days. Assume, you had 8 working Hours per day.

Time lost in each Build/compilation = 7-3=4 minutes.

24 cal. Weeks = 24 X 50 X (Time lost in each code compilation) = 120 days.

24 cal. Weeks = 24 X 50 X (4) = 4800 Min/60 =80 Person-Hours= 10 Person Days].

So for 6 Calendar Months of work the organization is losing 10 Person days per developer.

Doesn’t that is good eye opener for managers? I think that is quite a lot valuable time and that it is wasted just because you had not upgraded your hardware or software system.

Sometimes, many of us forget that we are using computers just because those damn good and fast machines can do tasks faster than human can think of.

Share this post :