What is a vision?

Leave a comment

The word vision brings up feelings of breath-taking vistas and simple clear grand statements. In truth it may be like that in the mind of the vision holder, but ‘getting it out there’ is more difficult. In addition a simple statement is easy to mis-interpret.

A vision is uSDLC parlance is more prosaic. If the vision holders can produce all the ideas that is burning in their brains then this can provide the basis from which a design can be fleshed out.

Think of a vision as a very high level design before it is catalogued and pigeon-holed. When it comes time to clarify and record the high level design, place it on a child page. The raw clarity of the original description continues to have value.

Owner Developers and uSDLC

Leave a comment

uSDLC addresses many of the weaknesses that plague owner developers while minimising the effect on the strengths.

I use the word minimise intentionally. The fastest way to produce something is to hold the design in your head and start coding. The risk is that you may end up with a product that is hard to maintain, hard to add features and buggy. You also risk not seeing your target until you have developed the wrong product.

uSDLC supports the use of behaviour driven development (BDD). It will help you sketch out your design with the least of documentation overhead. uSDLC also has an easy to use test driven design framework that will make this approach easy no matter what technology you are developing with.

In my experience, filling out the design adds less that a 5% overhead to the project – while it makes it easier to see the gaps and to plan what to do next. The test driven development (TDD) component of BDD is more expensive. It doubles the development effort. This sounds like a lot, but you get it all back with tenfold interest during the later development and maintenance phases – or at least that is the agile stance. As a more immediate bonus you will have more confidence in your software – and you won’t be wasting time finding bugs introduced by supposedly unrelated code changes. Oh, and when you decide to add a new feature, it is way easier.

Problems with traditional documentation

Leave a comment

User and reference manuals are usually scheduled, if at all, for the end of a project. The logic is that there is no point writing documentation until the product is complete – or it will only become out-of-date.

And then the creation. Document writers have to learn the running software without the benefit of documentation and often after key personnel have left the project. Often the technical writer is also a technical tester. The process is akin to archeology.

Ubiquitous Language – a Choice of words


Chris Matts originally suggested using

As a role
I want the system to do something
so that I get this business value

While it flows well, it emphasises the role and make the business value a result. One of the tenets of feature injection is that we start with the business value and pull our actions from that. Liz Keogh suggests in her blog using

In order to <deliver some business benefit>
As a <role> I want <some other role>
to <do something, or use or be restricted by some feature>

I have found that by adding the 5 Whys to the end at all levels of the design helps clarify the intent.

Why? <drilling down to the core value>
Why? <drilling down to the core value>
Why? <drilling down to the core value>
Why? <drilling down to the core value>
Why? <drilling down to the core value>

This is the default template I have used for uSDLC. It is easy to change as thinking in this area progresses.

What is Feature Injection?

Leave a comment


Chris Matts and Gojko Adzic describe feature injection in this 2011 article. While BDD provides the structure to drive development through behaviour and examples, feature injection links this to analysis by making features secondary to business value.

  1. Find core business value (the 5 whys)
  2. Find necessary goals and capabilities – with reference to stake-holders
  3. Find the right questions to ask
  4. Pull features from the information gathered above
  5. Use domain experts to find examples


What is BDD?

Leave a comment


Dan North coined the term BDD for behaviour-driven development. Initially he was considering it extends test-driven development. After further consideration, it became obvious it was a way to view both analysis and acceptance testing as well. Put simply, defining and verifying behaviour is far more powerful than creating and running tests.

Dan recognised the value of ubiquitous language as described in the book Domain Driven Design. His choice of As a … // I want … // so that … is valuable in analysis and design in providing focus.

He then hooks the world of words with that of code with scenarios – given … // when… then … These are domain language //natural language statements that are interpreted by the system to interact with the system under development. Confirming behaviour – or running a test under the old parlance.

Dan defines BDD from a software developer perspective, with a focus on features and scenarios to close the gap between design and development. To help span the requirements, design, development and testing, uSDLC uses the breakdown documented by Elizabeth Keogh in her blog on BDD in the large. She attributes the structure to Chris Matts, a business analyst who worked with Dan North extending BDD beyond the development tier. It is a part of feature injection.

This allows for a deeper structure with layers for project, vision, goals, capabilities, features and scenarios. For smaller projects, project, vision, features and scenarios prove an adequate breakdown. It appears that the same ubiquitous language (As a … // I want … // so that …) works for the earlier breakdown as well as for features.


Owner Developer Weaknesses

Leave a comment

On the other hand, most owner developers fail to finish. Here are some of the reasons:

  1. Too ambitious: Most owner developers start a project from a concept and move directly to implementation. Without other parties to satisfy, the design can stay cerebral where it can grow and adapt. This often works well – except for a perspective issue. An idea that looks like it should take six months can take 6 years – a fact we would have known if we had taken the time to jot down the tasks and add some guesstimates. Of course most owner developers would be to intimidated to start if they knew what they were really taking on. So, perhaps it is better to have a high failure rate than lose the great ideas that do make it.
  2. Commitment: The creative spark is important, but for software development it takes 99.9% perspiration to make the 0.1% inspiration valuable. That is a long road to hold your vision and belief for.
  3. Direction: It is easy to get immersed and spend an inordinate amount of time on features that are either dead ends or not needed for the first release of the product. This is one of the risks associated with the strength of flexibility.
  4. Organisation: Keep all aspects of a complex project in your head takes effort. While this effort is a lower overhead than that involved in a team project, it is still significant. It also leads to things being lost – from great ideas to potential pitfalls.
  5. Product reliability: relates to organisation deficiencies and the low manpower investment. Coding without formal design leads to gaps in implementation, particularly with error checking. In addition one person has to choose between fixing bugs and adding that new feature. As the product increases in popularity the bug fixing can take all your time.
  6. Marketing: Let’s face it. Software developers are mostly technical geeks with poor communication skills. If your product is something new, how do you tell people what it really does? If the idea is obvious there will already be a hundred versions around. If it is truly unique, why will your market know to look?

Older Entries

%d bloggers like this: