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 !