Trust in team environment

The following paragraph kind of sums it up when people ask what trust means for teams?

I believe you are competent to do the work

I believe that if you have an issue with me, you’ll bring it up directly
with me, not talk behind my back.

I believe will follow through on commitments—or let me know when you need
to renegotiate.

I believe you have good intentions towards me and the team.

What makes design...simple

Last weekend in the “Simple Design and Testing Conference” we had a discussion on “What makes Design Simple” and this is a summary of the discussion we had along with my thoughts.

Well before we go further with in our way of defining simple/complicated design we have to step back and first answer why do we design?

We design to be productive and I don’t do it if it is below the DesignPayoffLine. Now if you read What is software design which I highly recommend you will learn that we design all the time, when customer approves a story he/she makes a design decision (this is interesting, some times we evolve to complicated design when stories are not broken properly), when we write tests (we do test driven development) and programming is also a design activity. So I guess we are always designing with or without knowing it.

Being an agile developer, we don’t focus ourselves on BUFD (Big Up Front Design) but rather we believe in evolutionary design, a design that grows as your system grows and there are benefits of doing that which I will not discuss here (read http://martinfowler.com/articles/designDead.html). One of the key aspects of the evolutionary design is to do the “simplest thing that could possibly work” nothing less, nothing more. There are couple of things that needs to be noted here, “simplest” and “possibly”. Simplest or simplicity is your shortest path to the solution i.e. getting your idea from your head to screen as quickly as possible. And why it is possibly? Because we are not sure whether it will work and that’s why we write test to make sure that our idea works.

But the interesting part is we all start simple (I am totally ignoring the fact that there are teams that start with 200 page design document from day one) and it gets complicated over time because it starts doing more work. But if we could restrict ourselves to keep it simple for tomorrows need tomorrow then I guess we can preserve simplicity and this is where refactoring step fits in. Refactoring is our way to simplify things when it gets complicated. Einstein once said, "As simple as possible, but no simpler." And I think that makes sense here.

Wait a minute we haven’t defined simple design yet? I don’t think I can define simple in two lines but lets ask the question differently, “How will we know that our application design is simple?”

Software with simple design will enable team members to quickly respond to change. And as your design deteriorates, so does your ability to respond to change. This is really critical for agile projects (again ignoring rest 70% of teams who don't believe in agile, they really don’t care) because we embrace change and customer satisfaction is important to us. Kent beck calls it “reversibility” property of software. If we can change our decisions quickly it is not a big deal to get them right in the first place and that means less planning upfront (we are wrong most of the times anyways). There are some really good second order benefits to simple design, we get our work done sooner and it is easier to communicate our work with others (I am not sure about you but I still work as part of a team, collective ownership rings any bells?). Above of all it is less stressful to work with simple design.

So how can we keep our design simple? Testability

I absolutely agree with James Bach on " there are no best practices" but rather appropriate practices and I think the appropriate practice to keep your design simple is continue to write tests.

Testability is a characteristic of software application that provides ability to developers to write tests for their software application. In the world of TDD, we derive our design from tests and having that ability is very important. In fact if it is hard to write test, developers will stop writing tests especially new agile developers. It is very easy to get into “code and fix” mode under agile radar. If you are the only manager reading this article please pay attention to your developers when they say it is hard to test, this could be good indication that application design is deteriorating.

While discussing “What makes design simple” in the conference, Brain Marick raised one interesting point, we should strive for habitability, “The characteristic of source code that enable developers feel like home and place their hands on any item without having to think deeply about where it is”( read http://www.wirfs-brock.com/PDFs/DoesBeautifulCodeImply.pdf). We do spend good portion of our time everyday inside the code we are working on and habitability makes working easy. I guess more appropriate answer to the question “How will we know that our application design is simple?” would be habitability. If it is easy to work with your design, it is simple.

If you are still with me then probably some of these makes sense but if you were looking for top 10 practices for simple design sorry to disappoint. The only take way point is “Design for today, not for tomorrow”

What is the first thing that you know about project before starting it?

due date of the project and reality is nothing goes as you plan in this world.

Learning is your bottleneck

"Our civilization runs on software." It is therefore a tremendous privilege as well as a deep responsibility to be a software developer
Bjarne Stroustrup

I just started reading about “Agile Adoption Patterns” book and I must say I am already impressed. It starts with “Learning is the bottleneck” chapter that example how that is main problem with any project and how agile helps mitigate that risk.

Why learning is important? Because we cannot know everything about a project even you are doing software development for 20 years and unknowns are risk in projects. No two projects are same. Even if you end up using same technology set, your teammates are different or maybe it is a new organization. So we have to learn things as we go (no assumptions doesn’t help) by iterations.

Why it’s a bottleneck? Software project failures have a lot in common with airplane crashes. Just as pilots never intend to crash, software developers don't aim to fail. It is amazing to look at history of software failures, here are some reasons why software project fails

• Unrealistic or unarticulated project goals
• Inaccurate estimates of needed resources
• Badly defined system requirements
• Poor reporting of the project's status
• Unmanaged risks
• Poor communication among customers, developers, and users
• Use of immature technology
• Inability to handle the project's complexity
• Sloppy development practices
• Poor project management
• Stakeholder politics
• Commercial pressures

And it is quite interesting how all these reasons are somehow tied to not having a negative feedback cycle so that teams can make smaller mistakes and learn from them.
Only if we could have opportunity to rectify our oversights sooner!

Yes we can, we need a software development process that allows to us learn from our mistakes. The iterative nature of an agile process helps us to make small mistakes and fail fast helps us to make necessary corrections. And if we don’t pay enough attention to them we might end up as another failed project in the list. But wait is it only process that could save us from the misery? No it is always “people over process”. If we are not paying attention to our mistakes no process can help. We need people who are adaptive and ready to learn, “we need Cathedral builders not stonecutters”