the test driven experience

When considering the type of developer experience that you want to have, you must consider three main things.

  1. Who you work with.
  2. What language/project you work on.
  3. How you perform testing.

I want to mainly focus on the third item - it has the most profound impact.

There are only two forms of testing, automatic and manual - period, that’s it, only two - you either run tests via a testing framework or you run tests in the browser/console by hand. One is repeatable and the other is based on feature context.

In the case that you verify manually you are leaving the guarantee of functionality (present/future) in the hands of the people who know what the application should be able to do. Enter the QA team (or the developer) - who are charged with making sure that the application functionality is still available. They are the gate-keepers of the release.

In the case that your verification is automatic the guarantee of functionality and documentation lies within the tests and in turn the code. Others can make changes simplify, refactor, and extend knowing that if you break things a test will fail. You are the gate-keeper of the release.

The freedom this gives you as a developer is phenomenal. This is what you stand to gain.

agility in a waterfall world

The end result of all physical engineering endeavors is a product that can then be used without major modification for it’s entire life. If the product was good at the beginning then it is good near the end. The process that produces finished products is known as waterfall. The main challenge of engineering the physical world is that you cannot (easily) update the components which has entered the marketplace.

There are no partially completed bridges or buildings that we deem safe for transit or occupancy. The field of physical engineering it is all or nothing.

You wouldn’t use an alpha stage bridge, but you would use alpha software.

 The realm of software is fundamentally different. The software can be a mere shell and still it will satisfy a customer need. It does not need to be complete nor fully functional to improve the efficiency and happiness of its users. Future improvements to the user experience will be immediately available to current customers and offer selling points for potential customers. “We have 10K new users per/month” is more convincing that all the slide decks and take aways’ combined. It seems that tangibility in an intangible world is paramount.

The fact is that more people care about traction than features, because traction indicates features but the promise of features indicate nothing.

When you give someone a product they will eventually know how it all works and become bored; when you give someone a minimal product and expand the functionality over time, the user is more likely to feel satisfied with the product. In the field of software engineering, agility is king.

True agility is a release early, release often - test-driven - product centric approach that promotes user experience, engineer happiness and doesn’t introduce premature optimizations. True agility disregards all things the don’t provide immediate business value.

People are impatient and will not wait for the promise of future implementation. Your customers only care about how your product improves their lives now.

As an engineer in a waterfall world - stick to the simplest thing and steer clear of premature optimizations.