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

by Tom 25. October 2011 07:47

Introduction

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.

Prerequisites

How do you do it ?

More...

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.

Introduction

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.


Conclusion

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: Nerdbeers continued - We all win !!

by Tom 16. March 2011 14:40

Note: this post is the successor to the previous post on NerdBeers; if you have not read it yet, you might want to browse through that one first in order to have some context for this one.


Introduction

The initial development on the Nerdbeers app was started about two weeks ago, and I never imagined it to be such a big thing really; I just wanted to build a small app to prove to myself that I could write an app without falling in the usual architecture trap.

But things evolved quite a lot, or, to quote a famous book:

"Opportunities multiply as they are seized"
Sun Tzu - "The Art of War"

I will try to give you a short overview of the key things that happened in the past two weeks.

 

The components matched perfectly

As I had been reading around on the web about Manos, Kayak, Massive, lean software practices, getting things done, ..., I was looking for an opportunity. The main focus point for me was avoiding protocol/boilerplate code, and thus having as much functionality as possible while writing the smallest possible amount LOC (Lines Of Code)  .

The minute I saw the Nancy web framework at github I knew that this would have to be it; it had such a nice and clean syntax, and it was similar to the thing I had been thinking about building myself. After one of the main coders provided the idea of reimplementing nerddinner, I just started implementing it.

Doing this, I did notice that I needed some kind of a data access layer as wel. Looking for the ultimate LOC/efficiency, I opted for the relatively new Simple.Data, which looked like it was the tersest possible approach possible to data access for me.

They matched perfectly !

 

The components were really young OSS projects

Since both of the components were still in an early development phase, they were bound to have at least some bugs, so choosing a relatively new player on the block might seem like a stupid mistake to make, but in my opinion this was one of the best decisions:

By choosing very "young" open source projects, 
the contibutors were all willing and able to help me out
with my newbie issues in a very direct way.

Think about it: if you use a mature open-source component, the OSS contributors get flooded with support requests, and are probably being asked the same questions over and over again. If you choose a young project, the authors will probably notice your questions, and they even might be able to help you out directly.

While I was hoping for some help, I never expected such a massive amount of response.

 

The component authors all contributed a huge amount to the NerdBeers project

What happened here was WAY beyond my expectations: next to getting almost instant help from all the component authors over twitter, they even started looking at my code, telling me what could be improved, and they even launched a few pull requests.

Most of the "bugs in their components" were actually bugs in my app due to my malpractices, but they were always there to help me out.

They also liked the fact that Nerdbeers was an implementation which showed of the results of their labour.

After a numerous amount of tweets with @GrumpyDev, @TheCodeJunkie @MarkRendle and others, I finally had an app boilerplate ready.

Next to this, someone from appharbor (@troethom) helped me to resolve a "bug" in my solution so that I could deploy the app to a demo website (for free), and the maintainer of AutoTest.Net (@AckenPacken) was there to help me after a tweet, even though I just made a stupid mistake (using the wrong MSpec runner).

 

The NerdBeers development team - a.k.a. "Wow, it really does happen!"

Here is a confession:

Without all those brittle minds, this would never have happened.

I have had projects skyrocketing in the past during my professional career. IMHO the usual way to get this happening is following these steps:

 

  1. Think about an idea
  2. Care about it, grow it, be passionate about it
  3. Set an initial target: both in scope and time
  4. Start implementing it
  5. Ship it at the time you planned it - really early, no matter how bad it looks, even if it does not have any true functionality yet
  6. Get other people passionate about it, and try to trigger their intrests
  7. Go to step 1, hoping to have at least triggered the interest of a few persons who might join you in the process later on
If you want this to happen, I can tell you one thing in advance: it will be hard, you have to be really persistent. You will have to take shortcuts, make some tough decisions, and be prepared to take the blame. It also requires some experience in team lead, group dynamics, NLP, management techniques, sales techniques, especially for step 6.

If you manage to pull this off, you will notice that the team's interaction augments the individual team members achievements to a new high.

For Nerdbeers, step 6 happened naturally; it did not take any effort at all. Agreed, there was some persistence required for the first steps, and sending out a version like this might have even damaged my "being professional about software architecture" (LOL), but at least I got something out there.

Here is what happened: the people started caring. No effort from my side was required at all. Those people influenced other people, and those might actually influence other people. All by themselves, no extra effort required. While this might not be a "traditional" software team, I would still call it a team. Agreed, we communicate over twitter, instant messages, github, without having any real contacts, or even some kind of direction, but everybody cares and takes his responsibility. Which is great, especially so soon in something so small !!

Conclusion & things to consider

After two weeks in the project, we have progressed a lot. We still have a long way to go, but I am confident that we will get there. For me the journey is more important than the destination, and I have had a very interesting journey already. It kind of makes me wonder on the path that lies ahead of me. 

The app in itself is still pretty useless, but the real value is in the way it has been constructed, both technically and on a social level.

This experience also makes me wonder about the future of software development teams. As far as I know, everyone on the N-team has day jobs. We do not share a common language or country. Yet, we still manage to be quite effective in handling problems quite efficient.

This makes me think about my future projects. As a small ISV, I currently have to turn down some projects, because they are to big for a single person. Working like this makes me wonder whether I might be able to take on a bigger project, working in the same way as we did on the NerdBeers team, with people whom I trust from previous experiences. We could sit together in an office, but we would not need to.

Maybe that's what work 2.0 will be about: a truely global work environment in the comfort of your own home.

 

Signing off,

Tom

 

Bookmark and Share

Continuous thinking: just ship it - the story of NerdBeers

by Tom 7. March 2011 18:24

Note

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

Introduction

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.

 

Conclusion

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...


Update!!

There is a followup post here.

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


Calendar

<<  April 2014  >>
MoTuWeThFrSaSu
31123456
78910111213
14151617181920
21222324252627
2829301234
567891011

View posts in large calendar