Friday, February 15, 2013

An alternative take on current software practices - Udi Dahan





(Note: Some points are more relevant in the context of Enterprise Application Development)

The famous software personality ‘Udi Dahan’ gave a talk in Perth. I was lucky enough to be one of the attendees. After working in an enterprise environment for a while, I must say I agree with most of his ideas.

I’d like to note down my key learning from this session.

Key takeaways

  1. Software is hard to build. First developers need to accept that fact and then they need to work on convincing the other stake holders of the same.
  2. The common frailties of the human brain will work against you when building software. Being aware of these irrational behaviours of the brain can help you get better
  3. Do not accept or adapt technologies or methodologies because it’s popular (in-time) or proven. Being popular or proven is heavily contextual. You should choose whatever that works for your team at the given time and situation.
  4. Understand and ride the organizations decision making wave. Being more aware of organizational politics/workings will enable you to successfully deliver key changes to the products/services that you developer/support.


Brain Tricks and Software Development

There are some inbuilt and predictable irrationality in our thinking process. By being aware of these will help us to identify them when they actually occur and then to over come them.
  • Recency Bias

- This is a basic human condition where we are good at relating our current (recent) experiences with our recent (immediate past) decisions or incidents. But fail to identify relations between recent observations and past incidents / decisions. A software project can take years to finish and even more years to ‘fail’ or deemed as ‘successful’. By that time the decisions taken at the start of the project which has direct causality with the success of failure of the project is not identifiable. Even worse is when we attribute decisions taken late at the project as reasons for our success or failure.

- This hinders us from learning what worked and what didn’t in a software project which pushes us in the direction of committing the same mistakes over and over again. A strong ‘retrospective’ activity in your process can alleviate this bias to a certain degree.

  • In Group Bias

- This is a situation where we take a decision because our ‘group’ (team, organization, competitor, industry) has taken the same decision. In a way this is a way of distancing yourself from  the decision. In an Enterprise environment this is a classic ball-passing mechanism.

- Group bias clouds the critical thinking process required at a decision making time because you start with a preconceived idea. Classic examples are the almost instinctive decision to go with N-Tier-Architecture (UI-Service-BL-DAL-Database) for many software system that we design or a present day Microsoft house going for MVC - WebApi - Entitiy Framework - SqlServer technology selection.

Technology or Methodology Selection


  • Agile
- Agile is probably the most abused term in Software industry today. It’s projected as the single ‘pill’ that will save any given software project. However companies who are successful in delivering projects in Agile are the same companies who were successful in waterfall (RUP) days. On the other hand it’s amazing how much of similarities are there between RUP and Agile in the first place. So what does Agile bring to the table?
- The ceremonies and rituals surrounding ‘Agile’ (Most of them introduced and glorified by consultancy firms) are a distraction to the core values of ‘Agile’. Most organizations tend to get lost in the ceremony and ‘misses the train’ when it comes to delivering quality software. Instead they should focus on basics like improving team communication.




  • Unit Testing and TDD
- Unit Testing is useful only if you have ‘Units’ of code that aligns to the ‘Single Responsibility Pattern’. If your code is a ‘bowl of spaghetti’ your tests will be the same...and it will be coupled with the code as well. So 2 bowls of spaghetti instead of one and one mixed with the other...just perfect :).
- Unit test can test what you already know. Most of the time bugs are caused by things that you don’t know. So in principal unit tests are not good at finding bugs. In fact research has shown that code reviews are much better at finding defects as oppose to testing (automated or manual). If you are required to take a decision on where to put your team effort in to, always consider code reviews before unit tests.

  • Modelling the ‘Real’ world
- Software that is demanded by todays business is far more complex than 10-20 years ago. Software needs to handle various different scenarios that is not distinguishable in the real world. If your design is an attempt replicate the ‘real’ world you may be constraining your system.
- One example is the notion of a customer in the context of an online store. Who would you consider your customer out of the four;
    1. A user who browses your store
    2. A user who adds item to the cart but does not proceed
    3. A user who fills in all his billing and shipping info but quits before confirming
    4. A user who purchases items
A classic ‘Customer’ entity modeled after the real world ‘Customer’ might not be able to handle all these scenarios. As you can see the actual business process(es) are much more complex than the obvious ‘Customer buys a product’ scenario and it can be extremely useful to enrich the model beyond the real world entities.

  • There’s no silver bullet
- This has been said over and over again in the industry but we seem to be making the same mistakes still. No new technology, pattern, architecture or methodology will solve all or even most of your problems building software. It’s a matter of you using the correct ‘ingredient’ in appropriate ‘quantities’ at the required ‘time’. Udi gave a nice metaphor for this where it is similar to cooking a dish. You need to choose correct ingredients in proper quantities and add them at the correct time in order to have good quality or at least edible meal.

Riding the ‘Organizational’ wave

  • This has to be taken in a positive tone; As technical people who lack ‘Soft Skills’ to match business people, we at least need to be capable ‘sniffing’ the decision making process of the organization. (Note: This is inherently hard to access and understand for technical people)
  • This knowledge can enable us to time our technological decisions so that we have a higher chance of getting the buy-in from the business. Udi mentioned a story of the 3-Envelopes. If you can time the opening of the second envelop correctly, that will be the time you pitch the ‘Big Re-write’. (Or ‘Resume driven development’ either way you like to put it)
  • Also as ‘self aware smart people’, programmers (or technologists) tend to damage the ego of the people around them more often. You have to be patient and polite in an enterprise environment when you encounter some of the most ‘un-educated’ ideas. The basic rule is ‘Not to be a dick’ to others regardless of how smart or knowledgeable you are on a given problem or a solution.

Improving your skills


  • Given the fact a given developer has sufficient technical skills to do the job, it’s much more productive to work on improving your ‘Social Engineering or Soft’ skills. This will enable you

- To convince people to listen to you more often

- To be more aware of people around you and what they think / feel

- To work as a team

  • Start somewhere! Don’t wait or search for the perfect book to read or best training to attend to. Start somewhere...anywhere. There are enough quality material to keep you busy.
Post a Comment