Tag Archives: Learning Organization

Tapari Meetings

Today morning I was checking my Facebook account and came across Harvard Business Review article over “How to Run a Meeting” (https://hbr.org/1976/03/how-to-run-a-meeting). I was overwhelmed by sheer length of the article. I must admit, I hate those long, unfruitful and agenda-less meetings. I think everybody does, isn’t it?

I started wondering, why HBR need to write such a long article on such a simple thing that we assume that everybody knows. It is just matter of checking all peoples’ calendar and sending them meeting invite and put the subject, venue etc. and done. In meeting as well, its straight forward, one person usually be the host, put forth the agenda and we discuss and at the end of the meeting, we share minutes of the meeting and action points. What is such a difficult thing in taking meetings?

The problem is not in taking meetings, it’s all about how we looked at this tool of communication and how effectively it’s been used in corporate world. If you really look again in HBR article, it’s been written in year 1976 and still the advice applies and still HBR fellows thought it is relevant in today’s world. It also means, not much things has been changed since last 40 years. We all, still curse ill-executed meetings. Traditionally executed meetings are always failures and count towards loss of productivity. Can we do something differently? Can we change, how we conduct meetings?

My views had been bit different on how to conduct the meeting thing. I am a big believer of 37 Signal’s philosophy of “Meetings are toxic” but also not able to avoid meetings completely. From last 5-6 years, I have been trying something different for meetings with my teams. After practicing with various teams and with different size companies in India, I think, it has made many of our meetings more productive and kept teams engaged. Most important is, we saved a lot of time which we might have wasted in conducting meetings in traditional sense.

My method is simple. I call it “Tapari meetings”. Together all team-members go for tea/coffee outside the office on nearby Tapari (tea-stall on the streets or around the street corners in India). If you don’t want to go outside office for some reason, then go to office pantry or gather around coffee machine and without any formal settings, start to discuss the topics everyone wanted to discuss. The topics can vary from what we need to do today to anything that is relevant to project/work. If team is like still relevantly new to each other, then you can start with common un-official topics like Sports, bikes, cars or any tourist places or anything. The important point is, team as proceed further with this daily routine, develops their own rules. You do not have to worry about setting rules in stones. My experience is developer and test engineers even nailed difficult bugs just by discussing them in such informal meetings and even executives has taken big decisions this way.

Advantages of such “Tapari Meetings”:

  1. keeps your meetings cheerful and awake. Since people walk to the Tapari (Indian tea-stall on the streets or around the street corners) or coffee machines.
  2. Meeting will run only for the time, people are having their tea/coffee and interested in the discussion.
  3. If you don’t have any set agenda, you don’t waste other people’s time.At least they can have tea-coffee and come back to their place.
  4. Soft issues can also be resolved since there can be “one more cutting de na bhaiyya” (One more tea, please) to sort out the issues.
  5. People only speak to the point and thinking on the feet since they don’t have ppts and any kind of papers.
  6. Since its only meeting where you have to remember things afterword, my observations are, people tend to conclude on action points and not interested in receiving minutes of meetings afterwards.

I understand that there will be few people who will always question about such drastic changes like having meeting outside and without any dashboard, ppts or even paper but I request you to try this method for few weeks and you will see the results.

Failure of our (may be specific to India only) traditional office system is highlighted when we think work only happens when people are at desk. Surprisingly, even president of USA and Prime Minister of India can work out their deals while having tea and walk. Do you think, your work is more important and more complex than theirs?

Let me know your thoughts.

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 :