Why I cannot write

At times its hard to write about anything!

Its a while I have been thinking about this and I have found a convincing enough answer for 'Why is it hard?'. When I am new to a subject, I feel I don't know enough to write about it and I stay away. And after I have got a fair hand on the subject many of the things that I want to write about seems elementary.

Now that I have found it its time for me to get out of this mental block.

Well lived Life

I have heard many of neighbours talk about this man, who lives just across the road opposite my apartment, how much money he made selling his farm land to an apartment builder and still lives an impoverished life. About the small house he lives in, about his children who are still going to a local government school(where standard of education is assumed to be very low), about him not wearing expensive clothes and not having a car and a lot of other things he hasn't bought with money. I got curious about this man and had shared the story with some of my friends and colleagues and most of them responded 'its his wish', 'he is stupid' and many other similar versions. But yesterday one of colleague asked me a different question.

Think of an Engineer or a Doctor who has a life style that is good by your standards, if they get a fortune would you really become equally curious about them not buying bigger car, bigger villa or generally any more material pleasures? To genuinely answer that 'NO'.

This was a realisation, that my beliefs about 'my view of a well lived life' was not accurate. I have to start it all over again. Umair Haques blog on Is a well lived life worth anything? was very insightful and this one is my favorite!

Things I used to take for granted as an Agile Developer

I am lucky to have an opportunity to work with some of the worlds best software developers for past couple of years. TDD, Pair Programming, Continuous Integration, Fast Builds, Value Streams, User Stories and a lot of other goodness all became a norm that I have forgotten about my previous job where I used to get a source code checkout that compiles smoothly only on a lucky day.

The past few months was an eye opener about what is software development outside the cocoon.

High Specialisation My job was that of git helper and unit test script runner, we had a test script writer and developers all specialising in their on areas of work , leading to large number of handoffs.

Long Running Builds 2-3 Hrs. Build was running on an environment that is shared across the organisation and used by multiple teams and was not predictable.

Ad-hoc Workflow The work could move from any role to other in any direction at any point of time. A test complete to ready for analysis was not that uncommon.

Collaboration We did a lot of that! The ETL tool produced a single binary file that was checked into the version control. The team was supposed to work in parallel to improve the throughput. We often overwrote each others changes and collaborated closely to recover.

What is Done? Truly we had no clue what DONE meant. Our project was an upstream dependency for another project and we never knew that what the downstream needed. We used to complete our cards and claim points without even consulting the downstream project.

Unfinished Work We had a lot of that. Expectation was for everyone to move as fast as they can, to eventually realize that they cannot move any further. There were knowledge gaps, cyclic dependencies between each others work, integration failures which all took ages to resolve. We did not learn from that, instead we tried harder.

What is value stream? Our build was part of the by the downstream project build pipeline and the results were not considered in publishing a build. Our story wall was represented at the bottom side of the downstream project.The build remains red for days and sometimes weeks, but that did not have any impact on developing new functionality. Also see the point above on Ad-hoc workflow.

The Mythical Man Month


We attempted to add more developers, Subject Matter Experts, dedicated Business Analysts and there was very little improvement. It was frustrating to work under these constraints. But it was practical lesson of Deming's Red Bead theory, how most of the problems were systemic rather than people related.

Next time when I pair program, TDD, BDD or work on a build improvement, sit across dining table layout I will have a greater appreciation for all those goodnesses and ones who developed and supported an echo system for all those goodnesses to flourish!

Why the Customers are not Motivated to see the Features?

I have expressed my doubts about how often the business sees a feature file in one of previous posts How often Customers see your Features?

. Not knowing enough of why the customers are not motivated enough to look at the feature files I started looking at whats my role in it?

As a developer I influence the style of feature files a lot (we typically outnumber other roles in projects and our collective decibel levels seems to work ;) ) and the good practices from the programming world creeps into feature files. One such thing is DRY(Dont Repeat Yourself) and manifests as step reuse in Feature files.

An example explains this better.



Anyone would want to reuse the above step irrespective of the actual value of the shipping charge.

That seems quite right too.

How about when the shipping charge is 0(zero)?

That is technically correct, may work and also conforms to DRY, I am happy with my developer hat on.

But I just missed the most important thing, the word FREE. And with that my ability to communicate effectively with the business.



What other patterns affects the customer motivation to see the Feature Files as a collaboration aid?

pepper

How often customers see your feature files? (BDD)

I have spent a lot of time debating different styles of writing business features(especially using cucumber) with my colleagues, be it imperative vs declarative style, example driven specifications, executable specifications or variants of the above, they mostly turn out to be an endless non-conclusive debates.

I have always favored writing features as specifications, and make it more natural language like, as I thought doing so makes it easier to communicate with the business more effectively. But now I have my doubts, especially with some of my recent experience, whether this is worth the effort for two reasons

1. The business hardly ever sees feature files and
2. On those rare occasions the business sees the features, they are assisted by the analysts and so the style and language does not matter that much
   

I am curious to hear about your experiences !

Cuke it Right - Brevity vs Clarity of Cucumber Features

Hello World!

As you may have already guessed, the title of my post is influenced by Jonas Nicklas' blog post You're Cuking It Wrong. In this post and and a few others to follow, I will cover some more counter productive ways of using cucumber features that I have come across. And in this post I will show how brevity of a cucumber feature may seem appealing to a novice BDD/cucumber developer and how they end up ignoring the collaboration and communication benefits. Lets get started with an example


Does that look alright? The steps read reasonably well, with the exception of the angle brackets(<>). Now lets read the 'Given' step along with examples, ie; by substituting the variables from the 'Examples:' section.


They all read well in isolation but, the last example above changes the meaning of the step template completely from


to


And clearly it creates a lot of confusion, if the examples change the meaning of the scenario itself.

So how does anyone end up writing a scenario like that?Well, there was a phase in my cucumber learning when I knew only about 'Scenario's and was unaware of the 'Scenario Outline's. So with my limited knowledge, if I were to write scenarios for the above feature, I would have ended up with quite a few scenarios like


And so on. That is hard, quite a bit of duplication and a maintenance nightmare. Then there is the sudden enlightenment of 'Scenario Outline's and I start refactoring my scenarios to be something like below.



Now the gold card and silver card looks so similar that I feel like combining them.



That looks even better and I cannot resist my temptation remove some more duplication, and I end up with what we started with in this post.




The word 'the customer' in the 'Given' step above is not much valuable, with that in mind here is my attempt to rewrite the above scenario further.



We pretty much killed the 'Given' step. This is much more brief than having separate scenarios, however can seriously compromise understanding and communication. Consider adding few more similar given steps to the above scenario and the problems will be much more glaring.

Use examples for examples NOT behavior, and don't be deceived by the brevity.

Have you got similar experiences? Have some thoughts/suggestions/comments? Will be delighted to hear.

In my next post I will cover how 'Data vs Information' matters for cucumber scenarios.

P.S.This blog post was updated with Syntax Highlighting for Cucumber to improve readability.