Steps and principles in requirement specification

Principles:

• Vision - share the same vision
• Users - must participate
• Work practice - must be experienced
• Anchor - desicions

4 phases:

• Creation - of project
• Strategy - to implement
• Depth - to dig for needs
• Vision - to renew

6 elements of a decision-process:

• It is a generic problem and can only be solved by establishing a rule, a principle
• What are the boundary conditions, which must be satisfied
• What is right (not just acceptable)
• What compromises must be made
• What action must be taken to carry it out
• What feedback can test the validity of the decision

These are just some reminders of important artefacts during requirements digging.

User centric development

"All a computer can handle are abstractions. And abstractions can be relied on only if they are constantly checked against the concrete. Otherwise, they are certain to fail", Peter F. Drucker.

I think this quote says all about why you should constantly research the user.

Kafka - TDD - And a course in TDD with Roy Osherove

I just finished a 3-day TDD course with Roy Osherove. Here are some of my lessons.

"The right understanding of any matter and a misunderstanding of the same matter do not wholly exclude each other", Kafka. That is one of the ultimate issues with software development, and TDD helps addressing it. How?

The simple rules for TDD are:

1. Write a test that fails.
2. Make the test pass.
3. Refactor.

By following these rules I will also do:

• Investigate the problem domain, but not more than necessary, and make sure the assumptions are right.
• Implement code that works.
• Implement the right code.
• Start with a simple thing, that can be finished within short time, at least within a sprint.
• The development cycle will have small incremental changes, rather than larger code chunks which is harder to test.
• Decide when to do state-based testing and when to do interaction-testing.
• Do test reviews.

Other things I will do:

• Address legacy code with TDD.
• Consider not doing TDD, but right now TDD feels simpler than not doing TDD. Even though TDD is hard.
• Separate unit tests and integration tests.
• Do pair programming.
• Write more integration tests.
• Start learning code contracts (C# 4.0).
• Start learning specification by example and write acceptance tests.
• When I have made a new system, or learned a legacy system, I will make a video describing it
• Write down the coding conventions.

Other things I learned from Roy:

• How to learn things, and what ravines and plateaus are. (This is a part I feel need even more investigation, but not now.)
• Go mouse-less.
• Do coding katas for training. (I have already been doing this after the course, and will continue).

So TDD addresses the understanding/misunderstanding of issues by forcing you to make assumptions and implement the right code. Make it your choice to do it!

Before the TDD-course with Roy Osherove (10.08.2011)

I have done some TDD, but I am not satisfied with the experience so here are some questions and confusion I have before starting the course:

• TDD and state based testing using stubs -
  How can I write the test first if I don't know something about the data being worked on?
  So you should prototype before writing tests?
  But what about TDD then?
  Wouldn't it be better to model up some domain first?
  Then you might get better off writing an acceptance test first, using an example provided by some business specialist?
  
  
• Why do I ever need Mocks? -
  I can write acceptance tests or integration tests instead?
  Can interaction testing be replaced by code contracts in C# 4? - There is a new concept "Code Contracts" which let you apply pre conditions, post conditions, assertions and invariants. This lets you express requirements and promises between APIs. The contracts can be used to check your code for correctness at compile time.
  
  
• Why would I use mocks to verify multiple method calls?
  ....if I do not know what data and objects these method calls would return?
  
  
• Arrange, Act Assert is the same pattern used in acceptance tests? E.g. -
  Given, When, Then
  As a "user", I want "something", so that "benefit"
  
  
• Regarding bugs: Write a test that fails, then change the code to get the test to pass? -
  Hard to do in a legacy world?
  
  
• Refactor before introducing tests in legacy code systems?
  
  
• How to handle large amount of test data?
  
  
• How to handle tests and changing requirements?
  Especially during project start up when requirements are not "set"?
  
  
• Using IOC to get stubs?

I hope Roy can clarify and guide me into being a better developer!

From The Code Alpinist

Design Patterns

A quick note about design patterns, which I picked up from a Google talk. There are originally 3 different styles of patterns:

1. Creational patterns, e.g. factory method.
   
2. Structural patterns, e.g. bridge or facade.
   
3. Behavioral patterns, e.g. strategy or observer.
   

Design patterns are different from data structures and algorithms. Design patterns are "descriptions of communicating objects and classes that are customized to solve a general design problem i particular context" [Gof4].

In addition there has been established another pattern group: Concurrency patterns, e.g. Active object. This group is mentioned at the wiki site.

So the next thing will be to follow up and buy the Gof4 book.

Is your software built in a higgledy-piggledy fashion?

This is your application:

It works fine and is quite reliable. The GUI is simple, but effective.

This is how the application looks behind the GUI:

Is there a system at all?

The question is: Do you care about how it is wired behind the GUI and all the way to the power-plant? If your answer is no, stop reading and hope that you do not have to pay for an electrician ever.

How can you make sure your software is maintainable? If you search for "maintainable code" you get a lot of blogposts about this issue. Jeremy D. Miller has a post among the search results, which is quite good. Uncle Bob is not among the results, but should definetely be a good source, at lea
st for a description of the SOLID-priniciples. Neither Michael Feathers was in the search results, but he should be noticed for his book about legacy code and refactoring techniques.

But if you know these skills, is your application maintainable? It certainly helps caring about those skills and principles, but as Roy Osherove preaches, it should be testable as well. In addition to that I would say that your application also should follow some patterns, i.e. as described in Martin Fowler's "Patterns of Enterprise Application Architecture" - or as described in any other patterns' books.

In addition I would like to add a principle myself: Your application must be deliverable, as in it should be easy to installed, deployed or updated.

So that should conclude my little note about maintainability. Which is just another part of Robert Glass' definition of software quality.