Opinion: TDD and startups - you are all wrong (or right)

by Tom 6. March 2013 00:06


There has been a lot of buzz lately about a post of Uncle Bob Martin, who claims that skipping Test-driven design is the worst mistake you can make when in a startup. This generated a lot of yay-and-nays on the twitter sphere, with mostly black and white opinions. I think they might all be right, but miss one important distinction: you always need to formalize what you are working on...

"So what" - Miles Davis

In my opinion, you need something to drive your behavior of your app, or as you put it in the context of startups, you need something to drive your search for a market fit. So while TDD might provide you "better" code in the end, it is not the code that matters, it is the behavior of the code that is all important. TDD for a startup should help you to reason about that behavior, i.e. what exactly are you trying to achieve.

Defining in an explicit way what (and even why) you are going to do something before you do it, allows you to:

  • focus on your task
  • define scope
  • reason about it in a strategic way

If you are able to reason about what you are about to do in another way, please feel free. I can think of at least 5 ways to define what you are doing:

So, whatever comes naturally to you might be the best fit. The most important thing is making something explicit (aka "ze cunning plan"), as I have found out multiple times in the past: without a proper plan to support your vision, you are doomed to wander around in eternity, as you never have a proper definition of done and/or scope, or even priorities...

As a developer, the best fit for me is usually some kind of a bastardized combo of all the techniques mentioned above, even combined with some impact mapping or other DDD techniques...

On a sidenote: currently halfway into Vaughn's IDDD book, and this proves to be very helpfull as well, it's like Eric Evan's blue book, but written in a more accessible and pleasant way...


So in the end, what it all comes down to, is that you need a formal/explicit spec about what you are working on, whether that is a design doc, some unit tests or something else, does not really mather; just find out whatever fits your methods best.

Bookmark and Share

Fallacies of the tech recruitment process

by Tom 16. November 2012 08:49

Note: I would like to thank @gbarrs for reviewing my blog post almost instantly, and also the offer of @GraemeF, @MarkRendle, @swaggerdmangene and @moldyseaswimmer to be a reviewer. Without them, there would be a lot more Dunglish in this post...

Why I like my job.

I have been hooked into computers ever since I wrote my first few lines of Basic on my mothers' brand new TRS-80 Model 3 with 64Kb of ram and 2 - yes 2 !!! - diskdrives of a whopping 178Kb. (Actually, I did not write the code, but I copied it character by character from a textbook that might have looked like this, but in my defense, I was about 7 years old).

The first program probably looked like this:




Exciting, is it not? In the five years that followed, I learned almost every in and out of this machine, where to peek and poke in memory, how to set pixels on the screen (monochrome, 128x48 resolution, imagine that), which ASCII codes to send to my dot matrix printer to switch control modes, ...

When I was about twelve years old, I had written a drawing application, complete with circles, boxes, Bresenham lines, and even the possibility to print the graphics on the (very noisy) dot matrix printer (remember those printers which had to print on chained paper?).


Continuous thinking: Essay: Ease and simplicity in software architecture

by Tom 31. October 2012 10:21


“Almost all quality improvement comes via simplification of design, manufacturing... layout, processes, and procedures.” - Tom Peters

As I was tinkering around with Erlang/OTP and some other stuff, I suddenly experienced yet another "aha-erlebnis": there is a huge difference between something that is simple and something that is easy, but a lot of people tend to miss this rather important distinction.


Project YakShayQRS : another CQRS evolution

by Tom 19. March 2012 14:50


TL;DR: I managed to minimize the CQRS overhead even further.

Over the years, I have been trying to minimize CQRS in several iterations, even releasing a framework and a lib in doing so. Yet, I have still not been satisfied by the approach I reached. This time I once again am pretty satisfied with the way things turned out, and they actually seem to require even way less overhead...

How it works

The concept is quite simple: I use a generic message class to implement messaging. Next to this I use the virtual keyword:


  • A class can contain virtual properties; these properties define the unique key of the instance. (f.e. an "Account" class has a "protected virtual string AccountId {get;set;}").
  • When invoking a message on a class type, an instance is loaded where the unique key is loaded based on the match between the message parameters and the classes' virtual properties. A message only gets invoked if it contains all the virtual properties from the class.
  • In order to alter state, one should use a virtual method.
  • One can only send messages targetting non-virtual methods to a class instance.
  • Non-virtual methods should never alter state, but instead call a virtual method that alters the state...
  • When rebuilding state based on past events, only the messages targetting the virtual methods are invoked to rebuild the state; no messages are emitted.
The advantage: all the wiring is convention-based; and once you get it it is quite easy: altering state should only happen through virtual methods, but these virtual methods should never contain any logic and just alter state or do nothing. The intercepted call to the virtual method gets emitted and gets processed by any non-virtual methods in other classes (if the message matches the classes' key).

2010 - 2011: A retrospective

by Tom 27. December 2011 04:25

One of my main motivators, my youngest son Matisse #PrideAndJoy


I like the concept of retrospectives; it makes you self-reflect and think about the paths you followed and want to follow in the future. As it has been 2 years ago since my latest retrospective, I think doing a post on it right now might be a good idea.


Quick tip: How to do TDD/BDD and debug unit tests with Visual Studio Express editions

by Tom 25. October 2011 07:47


This article will show you how you can do TDD/BDD with Visual Studio Express editions. While most people say it is not possible, it is actually pretty easy.


How do you do it ?


Scritchy: CQRS without plumbing - a preview

by Tom 21. October 2011 17:02


CQRS is one of my architectural pet peeves, as you might have noticed from the numerous amount of blog posts I made on this subject. However, I noticed the concept is complicated and hard to grasp for newcomers to CQRS. I have been spiking numerous attempts of a framework that makes CQRS both more manageable and understandable, failed hundreds of times, and even published a few of my acceptable attempts as gists over at github...

A few days ago I was messing around with SignalR trying to setup again another CQRS attempt, and failed miserably.... However, 2 nights after that approach I had an ephiphany which had been lingering around in my head ever since.

Today I decided to get back to business, so this afternoon I started spiking a proof of concept (POC).

I think you will be happy to see that I managed to get most of the annoyance out of CQRS with this simple concept.


Continuous thinking: Nerdbeers - Providing business value by issue tracking

by Tom 31. March 2011 04:36

Note: this post is part of a series; you can find the first post here.


Well, another 14 days passed by for the NerdBeers project, and a lot has happened:

  • @Grumpydev added a proper design
  • I did some major refactoring in the FailingSqlite branch, which will allow us in the future to have full integration testing available for doing proper BDD (or top-down TDD, if you prefer to call it like that). Unfortunately this branch is still pending for integration due to some problems.
  • I got some followers/forks over at github (Yay!!)
  • Some more people offered to help me out
  • Both @MarkRendle and @NotMyself progressed a lot with both Simple.Data and Simple.Data.SQLite
  • Spring started; I enjoyed the sunshine outside with the kids and the Mrs.
  • Social obligations
    • My brother in law's house renovation deadline is approaching
    • My brother's birthday party
    • Lots of catching up with some friends
    • ...

So Nerdbeers has not really changed a lot ? Are you lamenting ???

No, in fact I am not, I spent quite a lot of time on trying to get the "FailingSqlite branch" going, but unfortunately I have not been able to finish it, so I can not integrate all my changes into the master branch.

After receiving a kind offer from someone to help me out on the project, he asked me what still needed to be implemented. This got me thinking:

In this project, I reject tools/methodology as long as possible. Since I noticed the project was starting to slip - I've spent a lot of time on it, but the Net result for the end user is still zero -, I wondered how I could prevent this from happening again.

After all, that is what Agile/Lean is all about: be as efficient as possible in what you do, and the minute you are getting less efficient, look back at what happened, and find a way to make sure it does not happen again.

I used this approach all the time in the Nerdbeers project: I started without any tests or IOC, I postponed them until the manual testing process was slowing me down/not error-prone enough. This might mean I have a suboptimal design, but since there is no real business value in this, I can safely neglect this. When the suboptimal design starts getting in the way of doing efficient development, I can always refactor.

Anyway, back to the slipping part.

How can I prevent this lamenting stuff ?

The reason for lamenting is quite straightforward: I need a proper way to determine my - and the contributor's priorities. So I started creating issues on github, and after a few attempts of tagging, I finally found a method that works for me. It is heavily inspired by the Kanban stuff I use all the time during dev.

This is what the open issues list currently looks like:


Whoa, that's a lot of tags!! Why is that ?

Well, because I need them; let's look at them one by one, in the order they are assigned:

  • Type: determine whether an issue is providing direct business value (bug or feature) or not (Tech)
  • Time: a very rough estimate how much time it might take to implement; the purpose is helping you prioritize issues
  • Care: this tag points to the person who is taking care of this issue (you could consider this a bit like an assignment)
  • Stat: (short for status) Using stat you can follow the progress of the task

I tried searching for the minimal amount of tags which would allow to determine the correct priorities.

Using these tags I found out that the huge branch I'm currently working on, does not really provide a lot of added business value, so I decided to lower the priority and make it a bottom one. This is actually something that happens a lot with projects: things get implemented because they are "cool", but they actually do not provide a lot of direct business value. These tags should help me to prioritize.

Another cool thing is that the closed issues list now actually provides some value:


Fixing the features

As I was thinking about all the possible features, I noticed that I was adding a lot of them, without actually thinking them through. Since I wanted to avoid adding features which do not provide business value, I decided to implement a BDD technique into my feature definition.

Lets take a look at this in detail:

As a site owner
I would like the Nerd
To be able to view a map of all upcoming nerdbeers
So that he can choose whether he would organise one himself, or just join another one

This uses my favorte BDD format for BDD stories: you inform the reader who wants the feature, for whom it is designated, what it is and what the business value is.

This approach actually made me remove some of the issues I had entered, and made me alter some others. Someone who looks at a feature should now be able to figure out a lot based on these four simple sentences.


While the app in itself has not really evolved a lot, the way we approached it now has; this is what Agile/Lean is all about to me: provide business value in small incremental steps, reducing waste/being efficient as much as you can. I am rather curious to know what the next step will be in this project !!!


Bookmark and Share

Continuous thinking: just ship it - the story of NerdBeers

by Tom 7. March 2011 18:24


This is the first in a series of posts :

  1. Continuous thinking: just ship it - the story of NerdBeers (this post)
  2. Continuous thinking: Nerdbeers continued - We all win !!
  3. Continuous thinking: Nerdbeers - Providing business value by issue tracking


Ok, I will admit it: I am a software architecture junkie. I love thinking about it, and try to use it in every app I can. I am an avid fan of CQRS (more info here), and I try to use it as much as possible.

Next to this, I am also a very big fan of BDD; to me it feels like there is nothing that even comes close to the process of describing a problem domain using the example stories.

I spend a huge amount of time on reading as much relevant articles as possible, joining discussions in newsgroups, on blogs. This has provided me quite a broad knowledge about software approaches one should use. (Think SOLID,BDD. ...)


Ok, stop bragging please, what is your point here ?

A while ago I got together with someone on a new idea (yes Geert, I am talking about you). We talked it through and started prototyping. So I set up a basic project, and built a CQRS architecture in order to get started, so we would have better scalable/testable/more maintainable code. In the mean time, the other person had already started prototyping, so I spend a few days converting his ADO code into a more appropriate model for CQRS, and convert everything.

I heard about the latest version of enitity framework, which had a code-first approach, and since I had been using fluent-nhibernate in the past for view storage, I decided to go for the new player on the block. Unfortunately, the EF apparently did not support Enum storage, so we had to adjust about 80% of the viewmodels.

After migrating everything, it seemed like the other person was implementing code in the wrong places. He has always been a DAL/ORM kind of person, so the whole CQRS thing was really confusing to him. (which is completely normal; cqrs requires a different mindset than CRUD, and I did not take in to account the rather steep learning process I had made in the past).

I can go on and on about this, but to cut a long story short, the project was temporarily postponed to an undefined later date...

I also quit another project like this because I lost intrest in the project while building up the whole required architecture setup and a few basic screens.

So a lot of effort resulted in ... absolutely nothing


Fast-Forward to a few months later

As time progressed, I read even more about architecture, learned some new frameworks on the way, and tried out a few things from which most did not even get to a usable phase. My software hobby projects were all seeded quickly, but abandoned even more quickly.

Until I read an article on the blog of Matt Mullenweg. The one phrase that kept lingering around in my mind was this one:

if you’re not embarrassed when you ship your first version you waited too long.

Wow! That is a strong statement !! So I decided that my next project would respect this statement; I was just waiting for the perfect opportunity to come along


And there it was...

I discovered NancyFx, a .Net web framework loosely inspired by the ruby/sinatra approach, as well as Simple.Data, which one can compare to the ruby ActiveRecord approach. If there is one web platform that is known for it's productivity, it has to be RubyOnRails. So I decided to give it a go, and merge the two in a new project.

As I was looking for an idea on an app to implement, @grumpydev told me he had been thinking about trying to implement something like NerdDinner.com, but maybe a bit more limited, and that I was free to try it.

So I came up with NerdBeers

After taking a few hurdles (cloning the NancyFx git repo,installing ruby, building, installing sqlce, building, installing F#, building, cloning the simple.data repo, building it, finding an SQLCE editor, finding a Migrator.Net that supported SQLCE 4.0 and building it), I started a basic web project, where I had an index screen showing all upcoming nerdbeers and the possibility to add a new one, and a details screen where one could edit a nerdbeer.

I ditched Migrator.Net, since it was making things to complicated at this phase of the project.

I published it at github, tweeted about it, and got some very enthousiastic reponses from the creators as well as from the community, even inluding some people whom I consider to be impossible to reach...

As I published my sourcecode to github, I was thinking about my idle appharbor test account that I requested a few weeks before... Continuous deployment is required if one wants to approach lean development.... So I started hacking/reading/making stupid mistakes. Luckily the people from appharbor were there to help me, and pointed out what was wrong.

So after a few attempts and sleepless nights, I had a pretty useless app online, but it looked kind of cool due to the tersness of the code.


NerdBeers... The story continues

Since I got so much positive responses to an app which was basically an empty shell, but showed a lot of potential, I was motivated enough to start hacking together something usable. After trying out a few things, checking out the Nancy sourcecode and bothering @GrumpyDev, @TheCodeJunkie and @MarkRendle with all my noob questions, I finally got around to publishing something usable - allbeit in a very limited way - .

It still looks ugly as hell, but I am a developer, not a designer. Strings are being pulled currently to help me out (=replace) the design.



For me, this approach was WAY OUT of my comfort zone, but apparently it does work... If I take out the time to build the libs and workaround the bugs, check the source, bothering people about it, I have published a usable app in about a day...

It still looks really ugly (both the design and the code), but it works in a very basic way. I also cut out every possible feature not needed (i.e. currently one does not even have a login), so I would be able to ship it fast. And I have to say it worked: the short cycles kept me productive/motivated, and the small featureset helped me to focus on what was really important.So I did ship something !!

As the libs for NancyFx and Simple.Data progress, we will get a very mature platform which will enable truly lean development.

You can see the demo application at http://NerdBeers.apphb.com.

For me this has been a valuable lesson, and from now on, I will try to respect these principles more and more... I hope you found this an interesting read, and if you have had a similar experience, do not hesitate to let me know...


There is a followup post here.

Bookmark and Share

Continuous thinking: The future of software

by Tom 15. December 2010 18:43


In this small article I am going to ventilate my recent thoughts on the evolutions and the future of software (both platform and development methodology). This is my first attempt for such an article, so please do not take it too serious. Maybe within 5 to 10 years time, one will be able to read this article and have a big laugh, but then again, I am hoping to get at least a few predictions right.

Application architecture

I think the next big thing leveraging software and it's development will be HTML5. The basic architecture would be like this:

  • the client will be a task-based GUI running on the HTML5 platform; HTML5 will be supported on most peripherals.
  • the GUI will be able to generate explicit commands (poco class instances) and query view data L/WS* (=local and/or from one or more webservices)
  • these commands will be handled L/WS*
  • when the command is executed, the changes will be propagated explicitly through events (=poco class instances), or change the view data directly
  • these events will be processed L/WS* and will update the respective view data L/WS*
  • viewdata can be generated and persisted locally and/or on the server, and syncing is a mather of syncing commands and events
  • commands, events and view data will probably be published through some kind of ATOM/ODATA-like interface (or persisted locally)
  • due to more and more microdata formats and standards, webservices will become interchangeable (think address lists for example)
  • All devices will get a webservice interface (think phones/peripherals in general), usually with a full REST implementation


This would imply that a well written app (in HTML5) would be able to:

  • query/consolidate microdata or other standardized formats locally and from multiple sources
  • disconnected apps could easily be synchronized
  • app components should be reusable, apps should be composed of multiple HTML5 components
  • it could work in both offline and online mode
  • it should support multiple media/input methods
  • apps should work on a plethora of platforms without to much effort

The environment/tools

In order to make this possible I expect the following

  • the development language of choice will probably need to be the same for both the webservice and the client-side. This does not need to be javascript; it can be an other language translated to javascript for the HTML5 side (think Coffeescript for example)
  • commands, events and the handlers should be first-class members of the language of choice, or at least offer a framework that makes it easy to use this.
  • there will be a registry which would contain the mappings to resources (either local or on one of more webservices) - this registry might be a webservice in itself, for example a webservice of registry for all your personal multimedia resources
  • sharing data between different platforms would become universal (think movies/music for example)
  • caching/syncing data should be as simple as calling a single function
  • replication/failover is a piece of cake to setup
  • CQRS/BDD will be hot
  • monitoring the infrastructure is easy
  • everything will become continuous: continuous integration through a buildserver, continuous testing (think autotest.Net for example), continuous deployment, continuous monitoring
  • authentication will also be done through webservices or through current http/SSL/OID/... implementations
  • some kind of universal search which goes through all resources in the registry should be possible


I think in the end we will get an application that sends commands to a bus, which is either handling things locally and/or on one or more webservices. The app will also be able to either query the local data or some webservice for view data.

The registry of webservices will make it possible to plugin your own stuff without much hassle, and caching/backup/failover/monitoring should all become a non-issue.

A few possible problems come to mind here, which might be excuses why my predictions could be false:

  • migrating/integrating legacy systems
  • software/Services ownership and -protection
  • CQRS/BDD acceptance might be hard for some devs
  • implementations differences of HTML5
  • REST webservices might be replaced by something faster/with less overhead (protobuf comes to my mind for example)

In the end, what it all comes down to, is finding a balance between simplicity, flexibility, complexity availability and concurrency.


Bookmark and Share

About Tom

     Tom Janssens op LinkedIn    Tom Janssens op twitter   Core bvba RSS

I build software and help organisations to get better at building software.

If you would like to know more or meet up, just give me a call at
+32 478 336 376.

More info about Tom and his company...

Tom's resume


<<  April 2014  >>

View posts in large calendar