Assumptions are not facts

I was recently in the non enviable position of recommending changing direction of a large set of projects after 6-8 months of planning

For clarity's sake: By large I mean 7 to 8 figures multi-year program . By changing direction I mean Changing one of the core technologies and Reorganizing the order in which we were building the system; bringing some deliverables a year ahead of the original schedule.

The original plan and technology recommendation were made before I joined the team, by people who I respect a lot. So, why the change?

I must clarify that I normally start with the assumption that people before me had good reasons to make the decisions they made. But following what you will read later in this post, I decided to ask "why?". I needed to understand those decisions to be able to represent them to senior management.

What I eventually realized was that the original plan and technology were based on a set of assumptions that hadn't been validated for 6 to 8 months, meanwhile the understanding of the system had increased and there had been some important changes to the organization.

The team was under pressure and hadn't stopped to validate the assumptions. What's more, many people in the team didn't even understand why the current direction.

At that point I recommended to STOP and verify assumptions. We brought the team together and brainstormed assumptions, identified conflicting assumptions and, most importantly, discarded the incorrect ones. With a new set of assumptions, we verified the original decisions and agreed that we would benefit from changing direction.

Assumptions are not facts
A very common problem with assumptions is that, after a while, they are taken as facts.

The most effective way to eliminate this problem is to avoid assumptions altogether and make our decisions purely based on facts. As the old saying says: If you assume you'll end up making an ASS of U and ME.

This is of course, easier said than done. Frequently we need to make decisions even when we don't have all the facts.

Here is what has worked for me:

• Identify assumptions
  This is probably the hardest part as not all the assumptions are relevant and most of us do not even realize when we are making assumptions. A good way to collect assumptions is to start from the decisions. Ask "Why?" if there is no concrete evidence for the answer, then it is an assumption. Another way is to ask "under which circumstance would you change the decision?". Usually the answer highlights the assumption.
• Document
  Write down and share what the assumption is, but most importantly, the consequence or impact of that assumption. This is, if the assumption changed how would the decision change.
  
• Verify
  Set the time to prove or disprove an assumption. If you can, then there is one less assumption to worry about.
• Challenge
  By challenging your own and other people's assumptions you avoid inertia.
• Review
  It is a good practice to review assumptions at predefined stages in the development cycle. Even more important is to review them when you identify change.
• Act
  If an assumption changes or is disproved, bring it up for discussion, review the decisions made based on that assumption and if necessary, recommend changing direction.

Doing the 180
It is not easy to do an about-face after having given all your arguments for the current decisions. However, having clearly stated assumptions can reduce the pain, and certainly show people that you are a professional that is not afraid to change directions if conditions change.

I'm back blogging. This time more agile

I'm back blogging. After a few months hiatus, I've decided to start posting again. First I thought it was that going on vacations had changed my rhythm, then I thought it was all the workload of an important project, or maybe the summer.

Finally I realized what it was. I chocked trying to do too much at once.

My original plan for this blog was to write my thoughts as they came. Short posts that wouldn't bore people. Over time I would add additional related thoughts. Eventually, those thoughts would be associated by the labels.

In methodology terms: I was planning to write things "agile". Write as much as I had in my mind.

Then I came to the topic of Troubleshooting. I had a simple thing to say but as I wrote, I thought I could add more and more, then I realized I had to add structure, and reword things and... and... I got stuck. Instead of publishing what I had, and later improve it, I went for a big bang approach.

If that sounds familiar it may be because that's how many software projects get cancelled. They start with a simple, great idea but instead of implementing it and making it evolve, we try to improve the idea and add things to make it perfect on the first pass. As the idea gets reviewed by other people, new features are added to the list. We start thinking bigger, and bigger needs better architecture. As it gets better we need more input; after 6 months or a year of reviews and talks and meetings, still, nothing to show for it.

Most likely, releasing early could have shown if the idea was good or not. And the features that were really missing would have been added over time. 6 months or a year later, after learning from our mistakes, we would have a system that we could improve, refactor, even rearchitect, but we would be doing it with real usage data, not pipe dreams in meeting rooms.

So, that's it, I have decided to start posting again. Sometimes the ideas will be raw, most likely I will get some wrong, but as I get feedback and receive comments and discuss with other people, I may come back and review them, or even write new posts with a clearer idea.

May this post be the first where I spill my raw thoughts.

Testers are my best friends

Some developers think that testers are mean. "How dare testers misuse this piece of software causing a bug?" Hence, they try to direct the testers, train them in the application, even tell them how to test and what to test including "where not to click". Sometimes that works with more junior testers.

Unfortunately if the testers do not use the application in ways "it wasn't meant to be used", you can be sure that users will do and will find those undiscovered bugs. I rather have the tester find the bugs that have a user find it. 

To make matters worst, those undiscovered bugs tend to be gaps in the specifications that say what the system should do but not what the system should not do, or how should it react to unexpected situations.

Experienced testers, on the other hand, know better and will not fall for the developers complains, They know that this level of testing for the unexpected is important for two different reasons:

The first reason has always marvelled me: Users will find ways to use an application for purposes or in ways you never even thought of. Even making features out of bugs.

The second reason is better known as Murphy's law. One day I was in the Lab helping test a stand alone desktop application. At one point the tester told me: Now, save the transaction. And as I pressed enter she proceeded to unplug the computer. I was cold: How would the system react? Will it corrupt the data? Will the system even start again? While that simple test on its own wouldn't be enough to answer those questions, at least it made me ask them and review the design to ensure we knew how the system would react. Now, every time I go through a website that requires me to follow a set of steps, and I suddenly loose connectivity and I'm forced to start over, I realize that the testers of that site didn't test for Murphy's law.

That experienced tester mentality can help us even before a single line of code has been written. If you have a seasoned testers during specification review, they will ask questions to understand how the system will react to the unexpected. Remember, the sooner you find a potential bug, the easier it is to avoid it.

In my personal experience, If you make testers your best friends, you will end up saving a lot of money and most importantly they will help you keep your reputation as a great developer. 

Making choices

A good enough choice made on time is better than a belated best choice

This has been my motto when making decisions. Do not get paralyzed by the fear of not making the best decision. As long as you make good enough decision.

After all, Software systems are complex and there is hardly ever a "perfect" answer to a problem. If spending 20% of the effort you can get an 80% good enough answer which is probably the right answer why waste your and everybody else's time.

Be lazy: Reduce the effort you put making choices. 

Of course, we know that making a quick decision does guarantee a good enough answer:

- The teacher asks little Johnny: Jonnny, quickly, what is 2 times 5

- To which little Johnny immediately replies:  It is 11, teacher

T - Johnny that's wrong!

J - You asked for speed, not accuracy.

But there are techniques to help you make quick "good enough" decisions

Some of those are explained on the TED talk How to make choosing easier.

In future posts I will expand each of them showing specific examples on how to apply these techniques to software development.

Cut - Reduce the number of alternatives;

Only decide between options that make a difference. In fact, in some cases you can reduce the options to 1, which reduces the effort to 0. To help you cut on the options you can use Patterns, Frameworks, Standards Guidelines.

Concretize - Make it real;

When evaluating options, weight the actual project requirements to make the final decision relevant. 

I've seen people evaluate designs, libraries or tools based on "features". While that makes for a good magazine article, it is usually misleading and usually leads to a least than optimal decision. Compared feature by feature one of the options may have more customizations or better support or be the favourite of (insert your tech guru here) but it may not be the best option your project. 

Categorize - we can handle more categories, less choices each

Don't try to make all decisions at once. Categorize the decisions by impact, area of the system or areas of responsibility.

A very common trap when making architectural or design decisions is trying to make all decisions at once. There are so many decisions to make that we get paralyzed and feel that we cannot start the project until we have made the right choice for each of them.

Condition for complexity - Gradually increase the complexity of the decisions.

This one of course goes along the three techniques above. After cutting, concretizing and categorizing; start by making the decisions with less options earlier, That will give you a sense of accomplishment and will probably drive other choices down the road. In fact, having many options usually means that the difference between them is not that big.

But wait, there is more!

As you see all of those techniques provide frameworks to help you make decisions, but they are not the only ones. In future I will tag as "Choices" post that I identify a posts, that can help you make better decisions. 

Do you have your favourite techniques?

Welcome to the Developer practices Blog

Developer practices? not a typo for Development Practices

The goal of this blog is to share my personal experience and findings on what makes a successful developer. Yes, part of it is how we code: Designing, programming, debugging, etc; but also what do we do when we aren't coding: Communication, preparation, time management, networking.

When I am coaching and mentoring other developers they are usually surprised by my two main personal reasons for implementing sound developer practices : Be lazy, be replaceable.

Then I go on to explain how those two reasons translate to being a professional developer. As you read this and the following posts I hope you'll see how most if not all good practices eventually lead to those two goals.

When is being lazy a good thing?

It is a good thing when you do things that make your work easier. It is called "working smart". 

Establishing and following good practices removes the grunt work and the guess work of your daily job and allows you to focus on what is really unique. You think about things once, not every time you are confronted with the same issue. In the end reducing the number of decisions increases your productivity.

I want to get out of this job!

I know this is not everyone's goal; some people are comfortable doing day in and day out the same thing and being considered "the experts". For me, the ability to finish a job ensuring that someone can take from where I left it allows me to constantly go to new things without being dragged back by my "expertise" in one area.

I hope to see you around regularly

This will start with a weekly blog, until I either run out of things to say and slow down or your feedback gives me more ideas to put on this pages.