my pride & joy

Introduction

In December 2008, I was doing my job as a freelance technical analyst for a big company. While it was a very interesting job in several ways, I felt that a burn-out was coming up. I had no idea whether this was due to the job, or due to my personal merits (a newborn and a one-year old son, lots of tasks and chores on my to-do list for our house, a busy social life, ...) Instead of waiting for the man with the hammer, I decided to be proactive about it, so I decided to quit the job and reinvent myself during 2009.

It has been both an interesting, very challenging and enriching year for me, with both high peaks and low valleys.

I decided to write this blog post in order to evaluate myself, and I am hoping that other people might find some inspiration in this as well.

The Initial Plan

I started the year with both a big and an average sized project which should at least have given me funds enough to get through my first year without any financial concessions.

Since the big project was a web application, I started to build my own reference architecture based on an ASP.NET MVC app. This has been a very enriching experience for me as I evaluated a lot of technologies and defined my current technology stack.

I will get into this in another part of this post.

What Happened

Both of the projects were fixed price projects for the same company. As I had done a very special consultancy job for one of the division leaders for that company, I had a very solid professional relationship based on trust and integrity with that person. Since I was going to implement the average sized project for him, and they were looking for extra resources, he asked me if I was interested in doing a project for another division as well.

This is the part where I took the wrong decision:

For the average sized project, we did not have a contract at all. I know this might sound stupid, but this was simply because we both knew we could trust each other...

Based on my previous experiences with this company and a tight deadline, I decided to put up a preliminary contract for the big project, thinking we would be able to agree on the titbits later. However, the project's scope grew by the second, and after working day and night, reimplementing stuff over and over again, and only billing a fraction of the time I invested, we got to the point where we could not get to an agreement any more...

Luckily, the trusted division leader was able to guard his own resources, so that I could at least finish his project and get it shipped/billed/paid.

In case you are wondering about the outcome of the big project, I will probably get the resulting verdict from my lawyer in February later on this year.

Lessons Learned

Reflecting on this, it is strange that such obvious facts as the following did not appear to me during the project, so that is why I mention them explicit here:

Always have a very detailed quote/contract that states everything in detail. Mention in the contract that every extra/change to the original quote/contract should be agreed upon in a contract appendix, no matter how small. The main reason for the scope creep was probably the fact that I had not been formal enough on their first (small) change requests which grew bigger and bigger each time.
It is not because you can trust a single person in a company on its word, that this is true for the entire company.
Spread your resources... You should not be dependent on a single company/person/project...

How to Avoid Making the Same Mistake Again

For every project, I now create a rude application prototype, as well as a list of use cases/BDD stories. I do not implement all bdd feature story details, but I do implement those which might point to issues.

Using both these tools, you have given the prospect an idea on what to expect on both the UI side and the behaviour, as well as an introduction to your approach on the project.

The biggest disadvantage of this approach is the amount of time you have to invest in a single quote, but if you do get the project, you can bill (part of) it back, since this is actual analysis.

Call me Captain Obvious, but it occurred to me that, in order to get a correct quote, you need to do your analysis upfront.

I posted a concrete example in this blog post.

Next to this, I am careful with bigger projects since they automatically imply a big risk when something goes wrong...

Was it a Completely Negative Experience ?

Luckily for me, it was not. At a certain moment, I needed to get some office supplies. When I entered the shop, the shop owner (with whom I had done a few small projects in the past) told me that he might have some opportunities for me... Talk about a coincidence! I started on some legacy code maintenance, and now I am slowly integrating more and more into his projects... So far so good. Also, while one part is ASP.NET MVC, another part is Windows Mobile, so this is now another experience I can add to my resume...

This brings me to my next part...

Broaden my Horizons on the Development/Technology Side

By building an ASP.NET MVC framework, I did not only broaden my horizon on the .NET side, but also on a lot of alternative technologies. If you are planning on doing any serious development, I would suggest you to at least study the following tools/technologies:

Tools/Technologies

An ORM: building your own ORM component in today's world is rather ridiculous in my humble opinion; there should be enough alternatives available right now. My final choice was Fluent NHibernate which allows me to define my classes based on a few conventions, and automatically wires the database for me.
Dependency injection: While I had already used it quite some time, this year, I fully grasped the advantages behind it. This helped my design skills a lot on the 'separation of concerns' and the testability part... I now favour composition over inheritance almost every time.
Proper POCO domain objects: I violated my POCO objects' principles a few times in the past, but I now finally got to the point where they no longer contain anything other than the bare necessities.
Using view models for building my pages: this made my code a lot more maintainable. I also implemented a command pattern for ASP.NET MVC; from that moment, all my links were wired in the controllers action (i.e. Viewmodel.AL_SubmitEdit = c=>c.AL("Save changes",c=>c.Save(null,null)) in the controller view set-up). This implies more extensive testability and removes all implicit references from the controller to the view; the view rendering is only dependent on the view model.
Using automapper to convert between domain objects and view models: this cleaned up my code a lot, since now all the mapping is defined in a single location.
Spark view engine: combining the use of view models with the spark view engine converted my aspx views from ugly ducklings into proper swans...
Other technology stack items: generic IRepository pattern, jQuery + plugins, Log4Net,PostSharp,...

Writing Quotes Using UI prototypes and BDD

Next to this, I wanted to avoid mismatching future quotes for my clients, and after studying my options for a while, I decided to go for UI prototypes together with BDD stories. The problem was I had never done anything BDD related at all. So I started studying/testing/implementing the whole lot.

I initially used Machine.Specifications as a bdd engine, but after using it for a few days I started implementing my own BDD engine, in order to learn more about BDD and to be able to implement the stories I want to implement within my own constraints. This has been a very valuable experience for me, I learned a lot on BDD and it got me started in OSS.

Get into Open Source/github

I like to learn from the web; by simply browsing and downloading stuff you can teach yourself a lot. As I had published a few articles on CodeProject as well as on my blog in the past, I decided to share my experiences with the rest of the world by going open source with my BDD engine and so I got started on github.

I never used github before, but in 2009, I had been studying git as well, and started using it with almost direct result as it made me do a lot more branching/checking in/checking out/experimenting in general without messing up anything at all. You could state that you could do this with any source control repository, but Git made it so easy and instantaneous that I used it a lot more.

Me vs "the world"^(tm)

Virtual Coworkers / Twitter

Next to this, I discovered twitter. You could ask yourself why this is important from a technology point of view. Well, this is why: working from my home, I do not have any direct contact with fellow devs/architects/... Twitter allows me to get in touch and ask opinions on a certain matter; once you get a few followers, it gives you the ability to use it as a sort of "online instant FAQ/opinions database". If you have a certain question or just simply want to show of, you can post it to twitter, and based on your followers, you will probably get some feedback as well as constructive criticism. Being part of this "huge brain" is also fun, since you can see ideas evolve quite a lot sometimes by giving your own input...

Public Visibility

I have also been posting some articles on CodeProject and my blog in order to get some opinions on a variety of subjects, some being more successful than others..

Productivity

And finally, the last I want to mention is the use of a personal kanban together with the pomodoro. I tested it, and it worked great for a few days, but then I started lamenting...

In this year, I will be using the kanban technique all the time, and probably the pomodoro as well. This should give me the ability to properly focus on getting things out of the door on time...

In Conclusion

While 2009 has been a very different year for me, I personally feel I learned a lot in this year; both direct and indirect. It enriched me both as a (business) person and as a developer on several aspects. If you feel a burn-out coming up, and you can somehow manage, try to take a year to do some things you feel the need for. Also note that most of the reasons for not doing this are not such a big issue after you name them, and look at the worst thing that could happen when it does come true...

Best wishes for 2010 !!!

Tom

2009 Retrospective: .NET technologies and lessons learned