What can Steven Segal teach us about development

While waiting for my virtual pc to start up, I thought about a quote a colleague of mine mentioned:
Assumption is the mother of all fuck up's - I cannot agree more!
In development there are a lot of assumptions to handle. How should you handle assumptions?

After reading an excellent summary of experiences with test-driven development, I find Fitnesse more and more interesting, or any other frameworks for writing acceptance tests, e.g. Cucumber. And Mike Cohn talks about acceptance-test-driven development in his book "Succeeding with Agile", as a primary role in defining what a system shall do.

So instead of making assumptions, why not help the customer to define a test you can implement as an acceptance-test. Then the there is nothing to assume any more.

The best intro to Fitnesse I have found, is Brett Shuchert's tutorials.

Christmas entertainment

This is really geeky but....

1935182471 SKEET, JON:C# IN DEPTH
-> I have some high expectations for this book after seeing Skeet at NDC 2010.

0961392142 TUFTE, EDWARD R.:VISUAL DISPLAY OF QUANTITATIVE INFORMATION
-> This book was recommended by Ryan Singer from 37 Signals. I really believe in doing "domain model-> gui,simple mockup -> development" in a short iteration. It combines domain-driven design with the agile disciplines.

Still on the wish list is:
Metaprogramming Ruby: Program Like the Ruby Pros (1934356476) av Perrotta, Paolo

-> But it will stay on the wish list because I believe Python is a more mature language so I'll stick to Google as a source for learning. Just search for "python metaprogramming".

Book review - Continuous Delivery, by Jez Humble and David Farley

I really enjoy reading this book. After reading some chapters, and parts of the remaining chapters, I think this is one of the important books to read. By important books, I mean;

• Agile Principles, Patterns, and Practices in C# by Robert C. Martin,
• Succeeding with Agile by Mike Cohn,
• Working Effectively with Legacy Code by Michael Feathers,
• Code Complete by Steve McConnell,
• Pragmatic Programmer by Andrew Hunt,
• The Art of Unit Testing by Roy Osherove,
• Facts and Fallacies of Software Engineering by Robert L. Glass

These books are quite practical oriented, and so is Continuous Delivery, but they do not claim it to be an academic book. They answer questions like:

• How long would it take your organization to deploy a change that involves just one single line of code?
• What is a deployment pipeline, and how to avoid antipatterns?
• How do I keep my application releasable?
• Common delivery problems, and how to avoid them?
• Automation over documentation!
• How should I mange a test-system and test-data?
• How do I do zero-downtime releases?
• How do I test non-functional requirements?

This is great! I guess any manager would find this material interesting, as it saves a lot of time and increases quality by a light-year.

As a developer I find it interesting because they bridge a gap between the IT-guys and the developers. Continuous Delivery is a step further from continuous integration. CI is a part of the CD process.

Read it, and you will be inspired! Do it, and you will succeed!

http://www.capris.no/product.aspx?isbn=0321601912

Who cares about quality?

In my experience quality is, unfortunately, not prioritized seriously. Why?

Developers and managers are not aware of the definition of quality. Therefore quality is somehow a random side of development, depending of the team skills. Robert Glass defines quality in his book "Facts and fallacies of software engineering" by Robert Glass.

Human engineering (Usability)
Usability is a big area. Anthony Franco's presentation at MIX10 does a good summary:

• Providing valuable Feedback
• Behaving with Consistency
• Behaving in a Familiar way
• Being obvious and Efficient
• Being responsive and Perform
• Helping people and businesses Accomplish goals
• Being brand consistent and Elegant
• Being progressive and Trustworthy

Understandable
This is about understandable code.

• Robert C. Martin's book Clean code
  
• Use well known patterns
• Coding conventions
• Good structure in the Visual studio solution.
  

Modifiable
The day you start coding, you are modifying your code. This is one of my favourites.

• Stay DRY
  
• Be SOLID
• PPP as described by Robert C. Martin
• Tests
• Refactor
  
• Understandable
• Follow Michael Feathers' advise in the book "Working Effectively with Legacy Code"
  

Portable
Is about creating software that is easily moved to another platform. May not be an attribute of quality at all, but for some the most important.

• Use Mono
• Monotouch
• Share parts of the codebase
• Use a coding language which supports several platforms
  

Reliable
Does the application do what it is supposed to do?

• Understand the problem domain
• Understand the users
• Understand the system domain
  

Efficient
Is about both time and space consumption.

• Analyse your code
• Do memory profiling
• Do performance profiling
  

Testable
Is the application easy to test?

• Roy Osherove.......... say no more
  

Conclusion
There is no finite definition of quality, but I believe Robert Glass makes a good one. You must order the attributes yourself, and ask yourself and the team if the application has these attributes of quality?

Picture is taken from the book "Kamikazekaniner"

Scott or Amundsen, who would you follow?

It is obvious, Scott died, Amundsen did not. What can we learn from an expedition like the journey to the South Pole?

Scott went for the "best" equipment (motors, dogs, horses), but failed. Amundsen used dogs and they wore clothes made of sealskin. On Amundsen's trip through the Northwest passage he learned from the local Netsilik people about arctic survival skills that proved very useful on the expedition to Antarctic.

In software development you must know your problem domain before you develop and finally go into deployment. This is what Amundsen did, he learned from domain experts, and this is what developers should do. Investigate the problem domain and write tests. When you know the domain well you will have a good base for writing tests. This will make your application safe and stable.

Another thing I like about mountaineers is that they practice a lot before they go for the real expedition. Like Tormod Granheim, who skied down from Mount Everest. He skied down a lot of other safer mountains before Mount Everest. Testing your application thorough, and close to the real environment, will make it stand a real situation.

Metaphors for software development are useful, but they will not be a complete analogy. Anyway, I like the mountaineering approach.

What does it take to do test first?

I am starting my task and the problem is, I do not know what test to write? So what should one do to follow a good principle to write the test first?

• Investigate the problem domain. Talk to your customer, talk to an expert in the field you are dealing with. What assumptions can you make? What conditions can you set? What goes in, and what comes out? Write user stories and prefer a pattern like "As a <type of user>, I want <some goal> so that <some reason>".

• At least write one acceptance test. Return later and write more acceptance tests. Prefer a pattern like "Given, When, Then".

• Write some quick code to investigate what your acceptance tests assume. A console application or just an integration test will do. If you need test-data, retrieve some.

• Write one, and only one, unit test. What states can you check? What behaviour can you test? Make it pass. Write another unit test...... now you are into TDD.

I believe many hesitate to go for TDD just because they do not know what tests to write. You hear Uncle Bob do his preaches of test first, but as anything else you learn, things usually are not black or white.

Knowing your problem domain gets you going to think about what you want to test. I believe this is starting designing: "...we need to really understand the problem space and find a solution... And also that it is a continuous process that will drive software development throughout the whole lifetime of the project.", Mark Nijhof.

Writing acceptance tests first makes you think about what you have to assume? What are the conditions? This is also a good start to document your work, which someone will be interested in. And it is good to have a customer agree with you, and to confirm your assumptions and conditions.

When you have come this far, you are beginning the most fun thing: Write code and make it pass your unit tests. And now you are 100% productive.

This is just one of my experiences starting TDD. I have tried to summarize it, rather then go into long details.