Kanban bubbles

Recently, a sunny day when my son and I went to the playground, there was a child blowing bubbles. The soap bubbles were flying higher and higher, sometimes they seemed to just hoover high up over the ground, suddenly take a dive and then back up in the air again. Both of us were fascinated.

"-Kanban bubbles."

I liked the sound of it. I guess there was some work issues processing in my head and the brain felt like combining work and play: Kanban bubbles.

At work, I am a part of a small team. We are about four team members working with software development, Kanban style. During the year we have changed stuff, improved things and experimented with tools like test driven development, pair and mob programming. We do, reflect and adjust.

We use a pretty standard way of visualizing our work, a Kanban board with swim lanes. In our agreed definition of done we have feedback (peer review) and exploratory testing as required activities after writing the code. One team member mostly gets to be the tester. The rest of us are mostly coders and peer reviewers. 

Our swim lane board doesn't really show that when all steps are passed, the release to production is done by the same team members that perform the first step. What goes around comes around. I tend to focus too much on the coding swim lane and too often miss what is happening at the right side of the board. Can our work be visualized in a different way?

Here is a suggestion, Kanban bubbles style.
The Whiteboard has two sections, the to-do area and the work in progress area. The to-do area is where we add stuff, prioritize and estimate. Important stuff at the top, not-so-important stuff at the bottom and we pick the most important stuff to work with.

Let's take a look at the work in progress area. In this drawing I have also added an imaginary circle.

Here I (sort of) have added our team definition of done steps and also tried to avoid those robotic terms that we usually see in Kanban and Scrum boards. After all, coders are humans, believe it or not.

In this picture one of the team members, let's call him Dave, has chosen something from the to-do area to work with. He moves the note to somewhere near Coding… word, draws a circle around it and a connector line to the word (make sure to only use those whiteboard pens, folks).

 

After some time the work in progress bubbles might look something like this.

What about limiting the work? By visualizing this way, there isn't very much space to add items, the actual (limited) space at the whiteboard is used for that. I think this way of visualizing probably is better suited for small teams.

The Kanban bubbles board is just an idea materialized from a moment of inspiration. Maybe our team will try this out in the real world, maybe not. The real world at the office is probably the only way to actually know if ideas are good or not. Or is it in the playground?

Hipster or neckbeard?

Man, that (asp.net) webforms thing really suck, doesn’t it? We should convert all our sites to mvc. For all the new stuff we’re about to develop, there is only one way: mvc. But wait a minute. I forgot to ask.

Why?

If you are developing stuff for the EPiServer CMS product, choosing between the two is a big thing these days. I think many EPiServer developers has felt left behind (myself included), being stuck with webforms when the rest of the world writes cool and awesome stuff with mvc and the frameworks that comes with it. I guess those poor SharePoint guys feel the same, don’t you think?

The times are different now. All of us can be cool these days (well, almost all of us. SharePoint will get there too some day).

Ok, so it’s about being cool?

Maybe. I would choose mvc because of one thing only: test driven development (tdd). Mvc is designed for that. Webforms isn’t. The rest is just style and preferences: design patterns, view engines, frameworks.

Is test driven development cool?

I think tdd is a great tool for helping you create both short term and long term value. The result will most likely be a product with nice and simple code. Nice & simple, as in easy to understand, maintain and refactor. Test driven development with webforms is mostly depressing. But hey, that is a different blog post.

Writing testable code, huh?

Well, I’m not really talking about just writing testable code. Don’t do that. Do test it & the code will follow. That's doing it the test driven way.

So who is the cool guy then, webforms or mvc?

I don’t know if anything used together with .NET and Visual Studio can be considered cool, really. We should probably check with @hipsterhacker or @neckbeardhacker about that. But don’t just settle with writing testable code with asp.net mvc. Without unit tests that proves it, the code base won’t probably be testable anyway.

So, without unit tests all that is left is choosing by style and preferences. Think about if that generates any value. Then make your decision on which way to go.

ps.

Check out my recent posts and videos on test driven development:

From the streets of test driven development: JavaScript

aspConf 2012 - Quick start: test driven development

ds.

From the streets of Test Driven Development: JavaScript

"... Let the unit testing drive your design. Write a unit test that specifies what should be done. Do a couple of variations if necessary, and then write the code that does the job. Switch back and forth between the unit tests and the code, refactor and clarify.

If you don't trust your code, write another unit test that provokes side effects. Do that until you feel confident. Then go home and have a good night sleep. ..."

Unknown
(Okay, it's me. I said that. I just thought it would be cool having a quote as an intro to this post)

Test driven JavaScript? 

Write a simple test, write a simple function. Done. 

That was the twitter version. What about the blog version? I think test driven development (TDD) is a good tool for helping you write code with high readability and a design with ease of use in mind (sometimes).

As a tool for testing (no matter what programming language you choose) TDD is overrated and quite often misunderstood. Probably because of the word Test in it, don't you think?

Before we start, I want you to don't care about stuff like code coverage, what frameworks to use and every line of code should have a corresponding unit test. That last thing is just nonsense. Think about the result, the code that actually will run in the production environment. The result is important. No matter how many nice unit tests there are, the result should be as simple as possible. Simple, as in easy to understand, maintain and refactor.

Simple is really difficult! I have failed with that many, many times (and still do, but never give up trying). What I have learned is that having a bunch of unit tests doesn't compensate for unnecessary complex production code. With or without unit tests, complicated code still sucks.

Also, don’t start the TDD journey by evaluating all those tools and worrying about continuous integration scenarios. Leave that for later. 

Do it the Agile way: experiment and learn.

"- Cool, I know unit testing already. I use that when writing C#. But TDD with JavaScript, how?"

If you come from a C# or Java background and already write unit tests (but have little experience of JavaScript) I think test driven development will help you understand and explore the language.

TDD has helped me to break free from the mindset chains of C# and Java style programming. JavaScript is not object oriented like in those languages. There are no classes, it is a language of functions and objects (and functions are objects). Objects can inherit from other objects and every object has a force field surrounding it (aka Closures) that is really powerful. Maybe we could call JavaScript the class less society? ...Because everyone has a function there.

Enough. (Want the basics? Check out my talk "Rediscover JavaScript" from dotNetConf.)

I have made a 15 minute video on how test driven development can be done with JavaScript and tried to write the code with simplicity in mind. I have avoided the common JavaScript language gotchas, like prototype inheritance and pseudo classes with the new or this keywords. In this video I use only one tool for unit testing (QUnit).

Take a look at the video and please share your thoughts about it!

direct link to the video on Youtube

Love letter to the Community

Almost two weeks ago dotNetConf took place, right here at the Internet. Sessions were broadcasted live and published on Youtube. It was a two day conference, with a total of 17 different sessions and speakers from at least three continents and a whole lot of different time zones.

The broadcasts were about 45 minutes long with ten minute breaks between the sessions. Everything was recorded with high quality video and audio that made it possible for everyone to follow the sessions in full screen mode. To be able to arrange a conference like this you would need great Infrastructure, sponsors with a lot of cash and a huge team. Right? 

Yes, no and no. Yes, dotNetConf had really good Infrastructure. But no sponsors and a very small team.

- How's that possible?

I think dotNetConf is really about Passion. And Fun. And Free. People passionate about what they do. Coding at work, coding after work, coding talks, coding in thoughts (coding in sleep?). People who want to learn new and cool stuff, share insights and all of this because it is fun! People who love what they do and they'll even do it for free.

- Dude, nothing's for free.

Okay, the guys that arranged dotNetConf most likey has spent a huge amount of their own time making this happen. And about $10 (!) for hosting the web site on Azure. With passion, time and $10 you can create a space where 2.400 people join live talks, demos and chat rooms. I think that is amazing.

Thousands of people from all over the world registered to the event. A couple of weeks later there is now a long tail of daily page views at the dotNetConf Youtube channel. As being one of the speakers I am stunned by the positive feedback I've got after my session. Thank you!

Here's the recording from my session Rediscover JavaScript. Please contact me if you have any questions or feedback about the presentation.

If you like the presentation style and level, you might be interested in checking out the video Quick Start: Test Driven Development from aspConf 2012.

Don't do it (share code).

"... You see, this profession is filled to the brim with unrealistic programmers. Programmers who thought their code would age like wine. If you mean it turns to vinegar, it does. If you mean it gets better with age, it don't. ..."

Marsellus Wallace (1994)

During my years as a software developer, I (and a lot of colleagues) have been thinking, talking and trying to figure out how to store and share our code. Code that we have spent time writing in the projects. I have always thought it would be nice if there was a common place to store stuff, to be reused in upcoming projects and shared between teams and local offices. That's a great idea, isn’t it?

No. It's not. It is actually a bad idea.

Recently I had a moment of enlightenment: stored code for later use is waste. When reusing code it creates waste and sometimes even confusion. Waste is expensive stuff. Confusion is risky stuff. Avoid it.

Here's an example:
Back in the .NET 1.1 days, do you remember what we needed to write to check if a string was null or empty? After a couple of projects I ended up writing a StringUtilities class with an IsEmpty method. Happy with the result I added it to a Common Utilities library in our version management system, for future use. If I remember it correctly, I also wrote my full name in the code comments section. (Today I don’t need that kind of confirmation. I have matured. I just settle with someone liking my current Facebook status.)

The next version of .NET of course had the IsNullOrEmpty method built in and that made my String Utilities code totally unnecessary. Too bad the class already had been reused all over the code base in an other project. And now people started to wonder:

- What weird stuff does that utilities code do? Why didn’t they use the built in method? Whatever. Better leave it as it is.

Another example:
Let’s say that we are about to write some c# code that should read RSS feeds and display them in a nice list. Before .NET 3.5, you would probably need to write a custom Feed class, a Feed Item class, and most likely a couple more of those custom classes. You would also need to write stuff that maps the RSS data with your custom classes. Once done, maybe it all should be stored in a Common Utilities folder for future use? 

Don’t do it!

Because in the future people will start to wonder:

- What weird stuff does that utilities code do? Why didn’t they use the built in SyndicationFeed class? I don’t understand. Better leave it as it is.

Both the string.IsNullOrEmpty method and the RSS Syndication namespace are part of the current .NET Framework. Code that is a part of the Framework is stable and (most likely) a lot more tested than our custom made ones.

Fine Code that we write today quickly turns into vinegar. Marsellus Wallace was right.

Okay, so Code is aging very quickly and that sucks. However, good ideas often stand the test of time. I think that we should rather share the ideas, and not the code. Use code only as an example to explain a concept. When understanding concepts, people will find better and modern ways to solve problems.

I think the same goes for Company policy Code Standards and Design Guidelines. Don’t spend too much time writing documents that will be buried forever in the Graveyard, aka the Intranet or Team Foundation Server.

The ideas and practices are better shared at informal lunch presentations and in blog posts. Maybe even in an Open Source project? Once the library or the blog post is out there, I mean really out there (outside the company firewalls and indexed by Google), it will be obvious to the world if it is fine wine (maintained) or vinegar (not maintained).

Got stuff to share? Invite your fellow geeks to a lunch session! Bring your laptop and start talking.


Mr Marsellus Wallace: