The Odd-e Blog

 
About the Author

I am an experienced coach in agile methods. I am also a Certified Scrum Trainer. I've written a couple of books with regard to scaling Scrum for larger organisations. I enjoy developing software especially open source ones. I love reading and reviewing books especially really old but good ones. I am currently residing in Singapore, originally from Holland. Get to know more about me from this page. You may contact me through email: basv@odd-e.com.

 

Singaporeans, wake up! Why software is eating your island


During the last months, I've been working on this article. It shares stories about the software industry in Singapore and my perspective on why it will have to improve a lot in the future. I've written this article because I've frequently have discussions on the subject, but actually do not have any place where I could publish it. Therefore, if you like it, I'd appreciate suggestions on where would be a good place to publish it (other than this blog). You can find the PDF version of the article here.

--------------------

Title: Singaporeans, wake up! Why software is eating your island

The old-world economies, US and Europe, are losing their advantage in 'old' industries such as consumer electronics and manufacturing, yet many don't seem to be bothered. Why? Even after years of outsourcing, US companies are still the frontrunners in the 'new' industries -- the software-centric industries. But Singapore is missing this boat.

A year ago, Marc Andreessen -- the founder of Netscape, a member of the board at HP and an important venture capitalist --  posted an important and wonderful article in the New York Times "Why Software is Eating the World".1 He describes how software is overtaking traditional businesses. The most frequently-stated example of this is the bankruptcy of Borders Bookstore in 2011 while the online bookstore Amazon.com -- a software company -- is still thriving. Closer to home, the biggest computer bookstore in Funan Digital Mall closed its doors the same year. These days, who buys technical books in a physical store?

In traditional companies, the role of software is changing from supporting the business to becoming the core business. These companies need to re-learn their 'new' core business... or else a new start-up software company will learn their 'old' core business and take over their market and they will end up like Borders or the Bookstore in Funan Mall.

In Singapore, this re-learning will be more intense. Why? In general, Singaporeans do not have an interest in learning or understanding software development (yes, there are exceptions). They'd rather be an analyst, salesman, marketeer, or even better... a manager. These jobs have traditionally been important, well-respected and well-paying but... Singaporeans, wake up! The world is changing. A career in management or sales might not be such a great idea in 2012. Careers in software are of increasing importance and you are missing all of it! If this attitude doesn't change then it will lead to mass unemployment and will seriously hit the Singaporean economy. Am I exaggerating? I don't believe so, please let me clarify.

Poor state of software

Software in Singapore is horrible. I find it unbelievable that companies can get away with badly-designed software of poor quality that isn't functional. Examples?

Singapore Air -- I enjoy ranting about Singapore Air as they provide so much to complain about. In 2011 they 'upgraded' their website. Their new website was so bad that I wasn't able to book a ticket online and I eventually changed airline. At that time, Nicholas Ionides, the spokesman for Singapore Air, reported: "As with any major IT project, we do expect teething problems but we expect to be able to iron out these issues in due course."2 No, Nicolas, projects like your website don't have teething problems, it is just shamefully poorly developed. In May 2012, Singapore Air reported an unexpected loss because of "weak travel demand and soaring jet full prices."3 A month later their site is down because it is "currently experiencing technical difficulties."4 Wonder where the weak travel demand comes from?

But perhaps Singapore Air is an exception? Not really...

Singapore Bank 5 #1 -- Our company used to have an account at Singapore Bank #1. We do all our banking via eBanking and, after a year, we changed bank as their eBanking doesn't support recurring payments -- a feature I had always assumed all eBanking systems had. The bank did always assign friendly relationship managers to us... but they seemed to miss the point: We don't need relationship managers, we need a proper eBanking system.

Singapore Bank #2 -- New bank, which does support recurring payments, yeah! We're switching banks again. Why? Their corporate eBanking can not report detailed real-time credit card information. But that's not all. Their credit card summary statements showed the wrong credit information. The bank even charged us late payment fees as we had paid the credit card based on the on-line information -- the wrong information. Their friendly relationship manager told us to use the paper statements instead, which we had always ignored. We seemed to have been the first customer to notice this huge and obvious bug, but after six months they still had not fixed it. To make matters worse, after six months they had conveniently forgotten about it. We're not sure what bank to choose next.

Singapore Stock Exchange -- A couple of months ago, I was in Hong Kong coaching at an international investment bank. I mentioned the sorry state of software development in Singapore and they all nodded in agreement and sighed. "You won't believe the Singapore stock exchange," they told me, "it is an absolute disaster."

There is hope as the government is promoting software development! Then again, how do most of the government web-sites look?

The case of the missing Singaporean developers

I mean no disrespect to construction workers, however it seems to me that Singaporeans view software development as construction work -- the dirty work done by cheap labor, the dirty work they don't want to do themselves. Every now and then I chat with computer science students and they often express the actual programming as a painful phase in their career which they have to go through in order to get promoted to something better. Promoted to project manager or business analyst -- or other jobs which I personally consider to have no future... but more about that later.

There are companies in Singapore who care about the state of their software. These are usually not Singaporean companies. An investment bank in Singapore which we work with trained all their developers in modern agile engineering practices and hardly any of them is Singaporean. Or, a start-up in Singapore of about 40 people with zero Singaporean developers. Recently, I met with a manager of an international embedded systems company in Singapore. He is Singaporean and I mentioned IDA CITREP subsidy for Singaporeans. He laughed and said that he was the only Singaporean in their team. A friend of mine is a CTO of a finance firm and his policy: "Never hire Singaporean developers as they do not know how to develop."

"Software development is unpopular because of the low salary," I'm often told. Therefore companies hire developers from India, Indonesia, Malaysia, Russia, United Kingdom, United States, France, Holland... But UK, US, and France are not 'low-wage' countries, so what is going on here? I asked exactly this question to a CTO of a finance firm and he replied that the good software developers get paid a lot higher salary than sales, marketing or project management. Why? It is easy to find sales people or wannabe managers but finding good developers is really difficult. Perhaps the low developer salary is a myth?

Talking about myths. Now and then I'm told that all software development in Europe and US is outsourced to low-wage countries. This amuses me as I never forgot the discussion I had with a CTO of a Finnish games company where he explained that the only reason for off-shoring work was that he couldn't find developers locally. Salary and the work environment for software development is good, so good in fact, that according to the Wall Street Journal, software engineer is the best job in the US in 2012.6

Yummy, an island

In January, I was in Shanghai and needed additional heating. A friend and I drove to the nearest electronics mall. I found the perfect heater and told the store assistant that I wanted to buy it. She said it was not for sale. Puzzled I looked for a less perfect one but that one was out of stock. I asked my friend what kind of mall this was -- why don't they sell things? He answered most people buy things online, not in malls!

This fundamental shift will also happen in Singapore. Software is becoming part of the core business of organizations and, with that transition, software development is a core skill to have. But in this fast-paced, software-intensive world, the software developers must deeply understand the business they are working in and work directly with users and customers to create the best solutions. The days of software developers who only understand technology and who wait for analysts to specify the work are over. Software developers need to broaden their skill, understand their domain and remove the wasteful handoff of information from analysts.

Related to this shift is the change in management style often called 'Agile'7 where cross-functional teams work directly with users and customers using short iterative feedback cycles. Some management responsibilities, especially project management, are delegated to these self-managing teams so they can respond quickly to the needs of customers. The team members balance between deep specialization and being enough of a generalist to always move the team forward. This delegation to self-managing teams who balance specialization and generalization makes specialized management jobs such as project manager gradually obsolete.

In Singapore, this shift will be tough as it requires cultural change on three different levels. On an organizational level, organizations need to understand software rather than looking at it as a cost centre which is best out-sourced and off-shored. On a management level, management need to empower people and create inspiring places to work rather than the hierarchy and micro-management control that is unfortunately common in Singaporean companies. And on the national level, we need to create a national culture wherein people chose a software development career rather than considering it beneath them.

Currently Singapore is going in the opposite direction. Universities do not promote engineering careers and the recent, stiffer criteria on employment passes8 will make it even harder to find great software developers. I definitively hope this will not lead to companies pulling their development out of Singapore. If it does then that will definitively take a big bite out of Singapore's old-fashioned economy.

------------
1. http://online.wsj.com/article/SB10001424053111903480904576512250915629460.html
2. Reported in Straits Times
3. Reported in Reuters news (9 May)
4. Reported on Singapore Air website
5. Original names are removed for now as that wasn't the point.
6. http://online.wsj.com/article/SB10001424052702303772904577336230132805276.html
7. http://www.forbes.com/sites/stevedenning/2012/04/09/the-best-kept-management-secret-on-the-planet-agile/
8. http://www.straitstimes.com/The-Big-Story/The-Big-Story-3/Story/STIStory_702077.html

 

Book Review: There's always a duck


"There's always a duck" is a LeanPub book written by Elisabeth Hendrickson (a friend of mine). You can find the book here. Since it is a LeanPub book, I can't review it on Amazon.com therefore I'll just post it on my blog. Is this the gradual end of Amazon.com who gets taken over by internet-age publishing companies? Who knows.

Anyways, There's Always a Duck is a collection of articles and blog posts that Elisabeth has posted over the last, well, 15 years or so. The book is names after the first article with the same name. The book consists of eight named parts with each about 5 articles under it. It is around 170 pages with huge fonts.

It is hard to summarize the book as it really are independent articles which are sometimes 'accidentally' linked together. The articles are Elisabeths observations of her experiences and the lessons she has drawn from it. This could be her daughter telling her that she always sees ducks with which Elisabeth concludes that if you look carefully, you'll see familiar things around. Or the description of "normal coffee" in India with which she concludes that even 'simple' terms such as 'normal' depend a lot of who is saying them and in what context.

Most of her later articles tend to be related to Agile development, whereas her earlier articles tend to be more testing focused. Yet all of the articles have some useful lesson in it. Articles are short and easy to read which makes the book a perfect reading book for short moments in which you have nothing better to do like sitting in the train or waiting in a queue :)

Though I'm probably biased, I did enjoy the book quite a lot. It isn't a wow book that I would recommend to everyone, but it is an enjoyable book full with useful anecdotes which make you laugh and are useful. From that perspective, I would recommend it as a book that you can every now and then pick up and read an article. I'd rate the book probably 4 out of 5 stars, better than "ok" yet not a book that I'll be recommending to everyone.

I do recommend getting this book simply because if it self-published and authors like Elisabeth ought to get more support via their self-published work :)

 

Prefer to do DO over DI


Today, accidentally, we invented a new term: Dependency Objection :)

We started using dependency objection in design by preventing dependencies so that we don't need to inject them anymore later. Thus prefer to do DO over DI.

Interesting...

 

Waterfall strikes again? -> Singaporeair site s*cks


Singapore Airlines is one of the worlds most respected airlines. They keep winning airline awards. I happened to live in Singapore and therefore it is most easy for me to fly Singaporeair. And, I have to admit, it is one of the better airlines and I especially notice this when I fly other airlines.

A well respected company. Known for its good service. A national company many Singaporeans are proud of. Yet, last week, they made an unbelievable F*** U*. So bad, that I'm seriously considering of starting to fly other airlines. Even though it doesn't relate to their flights but... their website.

Last week, Singaporeair did a sudden deployment of a totally new site. Absolutely no incremental deployments, but what seems to be perhaps years of work, suddenly deployed all at ones. I have heard that the company doing this for Singaporeair is... Accenture! (couldn't find anything on the web). And it is an absolute disaster. At first, I just thought the UI was bad, but no... the whole site is bad... but that's not all. The last days I have not been able to buy tickets anymore, which I assume is the main purpose of the site. Every time I try to buy a ticket, I get "system error". Everything in this deployment smells like a waterfall project gone very bad. But let me dive a bit deeper.

First, this was an all-at-once deployment, whereas it seems it would have been "easy" to do it incrementally. But lets assume that it is done "all-at-once" because of difficult technology changes. Even then, the old-site of Singaporeair was gone! Why would they run that risk and not, instead, have the old and the new site running together at the same time. Even the ISP I used for years (pair.com), they never swapped out their webmail at once, but kept the new site as a beta next to the old site. With a site where, I guess, a large part of your purchases come from, why would a company like Singapore Air run the risk of loosing that income (which they have now)?

All-at-once deployment aside, I'm not a UI expert, but the new UI sucks enormously. Not only make the choice of colors and fonts it hard to read, also it takes me a longer to buy a ticket (the one time I succeeded) because there are en enormous amount of clicks. Also a lot of technology seems off or used wrongly, which is visible by e.g. 1Password not working anymore for payments. Not only did they change their site, but also their booking confirmation emails (WHY!?). They didn't bother to inform tripit.com about that so that all the frequent travelers using both these services are not able to combine them. UI-wise, these things ought to have been discovered with earlier review cycles (sprint reviews) as they seem so obvious. If they would have bothered to take one frequent user of the site and let them use it, it would have been obvious. Why am I so sure? Well, just google Singaporeair and new site and you'll find complains for example on BusinessTraveler such as "Awful is an understatement" or Australian Frequent Flyer Community such as "Gotta say that I hate the new website." I mean, that is obvious and should have been found way earlier in the development. Not sure how this site was developed, but it smells like a pure waterfall.

All that aside, if I could use it, I would be somewhat happy. But if I try booking a (try it!) from "Singapore" to "Salt Lake City" date of departure "August 5", date of return "August 12", I'll get:

System Error

A system error has occurred. Please try again.

(R6HNNg!1307814381)


I tried it again and again the whole week. I reported a bug even. But no luck, it seems to not be possible anymore to book a ticket with the new site. This is truly unbelievable, how could a respected company such as Singapore Air allow to deploy a website which is SO BUGGY that even the basic functionality which is the main revenue stream for the company... does not work!

This was reported in the local newspaper: Straights Times in their article "Bumpy start foe SIA's new website". Didn't read the whole article (don't want to subscribe to straights times) but the most amazing part of the preview is the responds from Singaporeair Spokesman Nicholas Ionides:

'As with any major IT project, we do expect teething problems but we expect to be able to iron out these issues in due course. We will closely monitor the website's performance, and make adjustments where necessary.'

So, deploying an all-at-once, unusable, buggy and slow website in 2011 is *still* expected? I do not know where Nicholas has been the last 10 years, but I wouldn't expect it and find it truly shameful.



 

Satir/Weinberg Change Curve or "That model is wrong?"


This post relates to a post written by a friend George Dinwiddie related to the Satir Change Model. In the post he refers to a tweet I made related to the Satir Change Model. I'd like to add some clarification and argue that it is not "just a model" :)

Over the last year, I've started to get a little annoyed with the Satir Change Curve. You can find this in nearly every Agile development book. An example of the curve can be found here. I've used the change curve myself in the past, so why my annoyance?

The diagram expresses an assumption that all change will improve the performance, which we all know, is untrue. If we all know this assumption is untrue, then why would it matter? It matters in the way the change curve is used.

Imagine I'm a consultant promoting reverse-typing-driven-development. It's a wonderful idea where we switch out editor to type from right to left and we start each line of code with the end. As a consultant, I collected all this evidence in brain research showing that right-to-left typing and reverse thinking enables more brain connections and thus making developers more creative, smarter and better. It will improve the performance! So, I go to a team and train them in RTDD. They start off, but it feels a bit uncomfortable in the beginning. I grab out the Satir Change Curve and tell them that that's normal. The earlier way of typing was their status-quo and this change is a foreign element, so their performance will decrease and you will be in chaos! The team accepts my wisdom on change, after all, Satir was a family therapist. Eventually they get used to it, they stop complaining and keep typing in reverse. I declare victory and use them as an example of a successful adoption of RTDD.

The above is exaggerated, but there are a couple of interesting lessons in it. First, the actual measure of performance was missing. This is common and probably a reality of the industry we work in. In product development, especially in software development, there are so much variables that nearly every measure of performance fails. The change in the example was made for productivity and especially productivity in software development is not measurable.

But, I think the most important lesson of the story is that the change model caused the team and the consultant to stop challenging and thinking about the idea. Especially the consultant, he assumed the RTDD working style will improve performance (independently from context) and with that assumption he closed his mind for learning further. This is a very common problem which happens to me also a lot--I know the solution, so no need to think about that anymore, I just need to figure out how to get through the resistance of the people. Very dangerous.

Is the Satir change curve useless? No, probably not, there is definitively some truth in it. This is where the discussion a couple weeks ago became very interesting. I grabbed my Virginia Satir book to look for the curve and... it wasn't there! Now, I'm not a Satir expert, but I couldn't find a direct reference on the Internet either. (If I'm wrong, please, anyone, correct me!). The main reference on the Satir Change Curve seems to come from Gerald Weinberg. So, the curve actually should be called the Weinberg Change Curve and should be separated from the Satir Change Model. Most of this post relates to the Weinberg Change Curve and not the Satir Change Model. Is the Weinberg Change Curve useless? No, neither, but it can be easily misused. (Note: I don't have all of Satir's work and if anyone discovers that this paragraph is nonsense, then please let me know! I'd love to learn more about how the curve and the model relate)

One last thing. George's post was called "It's just a model" and we need to keep that in mind. I agree and yet also disagree with that. I agree it is "just a model" and a simplification. However, models contain assumptions and when models promote wrong/dangerous assumptions, then the model itself becomes dangerous. If that is the case (I'm not saying it is related to the Weinberg Change Curve), then instead of saying "Oh, it's just a model," we ought to say "that model is wrong!"


 

Organizational changes to support one team

In the previous blog post, I gave a list of points when adopting agile in an organization. One of them was:

  • Start with one team but immediately make the organizational changes needed to support that one team.

But what does that mean "the organizational changes needed to support that one team" ?

I usually recommend four organizational considerations when getting one team to work. (they are actually 3, but one is repeated for stress):

  • Dedicated cross-functional teams
  • Define "done"
  • All work flows via the PO
  • Keep out project managers

Let me clarify these:

Dedicated teams

This is probably the biggest change. With a dedicated team, I mean a team where the team members are for 100% on this one team. Also, the team is not temporary... it is not "just a project team". The team members know the change is serious... so serious that this change needs to be reflected in the organization. The members of the team have to report to the same "line" manager--without this it causes the confusion of conflicting loyalties. The team should take a shared responsibility for all the work. Specialization should blur. But when people report to a functional manager then this will be an restraining force which causes people to focus on "their area". To break this and to show that the initial Scrum pilots are serious, the organization has to reflect this in their org chart.

Define Done

The "definition of Done" defines the scope of the organizational change (the one mentioned in point #1). If we include technical writing, systems integration testing in the initial definition of done, then the people with these skills need to be taken out of their silos and put in the dedicated team. However, when the definition of done is smaller, it would lead to less change (but more delay and risk!). So, an organization adopting Scrum needs to define done to decide on the scope of the change.

All work flows via the PO

Teams need to focus to get work done! Focus, one of the original values in Scrum, is difficult when the team is interrupted from many directions. To get the initial team to work well, they need to be clear on what the work is that they need to do and where this comes from. Make this clear in your organization that the team is off-limit and that if anyone wants work from the team then that person needs to talk to the PO.

Keep the project managers out

This is the same as the previous point but it seems useful to repeat it. Project manager is not a Scrum role and the project management responsibilities are divided over the three other Scrum roles. Adding a project manager to a Scrum organization causes enormous confusion in responsibilities and dis-empowered Product Owners and ScrumMasters. To avoid this, make sure the project managers in your organization know that a Scrum project is off-limits. If management wants status of the project, they need to ask the Product Owner.

These four points seem simple but are incredibly hard to implement in an organization. However, they can be implemented on a team-by-team basis and that enables a gradual transformation of the work... and the organization.

 

Tips when adopting agile

I'm frequently asked whether I got tips for how to start an agile adoption. A lot of people are looking for the ten step magic recipe that will magically transform their organization to an agile organization. I tend to reply with the 'bad' news first: Every organization is different and it probably takes a long time... think years not months. That said. Over the years I've collected small tips which helped organization I worked with. Some come from organizations that tried them out and it worked really well... others come from organizations that tried out the opposite and it was a disaster.

Here they are, tips for adopting agile:

  • Avoid forcing Scrum on people and instead find people who are willing to try.
  • Get enough training so that all people have the same understanding. Differences in understanding is a common failure point.
  • Go See how things *really* happen. Talk to everyone. Look at code and tests.
  • Start with one team but immediately make the organizational changes needed to support that one team.
  • When adopting Scrum, also focus on the technical practices that are needed. Technical and organizational agility have to go hand-in-hand.
  • Do not buy any agile tools. Tools are unlikely to be the main problem.
  • Do not change Scrum or the technical practices without first many months of practices
  • Get in coaches. Organizations that want to do it all by themselves usually make a lot slower progress. This will be a huge change and getting help is a good idea.
  • Make sure the team is co-located and has an "agile-friendly" office environment.

Why just these tips? I don't know. From my experience, these seem to be of major importance.

Me and Craig have given more adoption advice in our "Inspect & Adapt" chapter of the "Practices for Scaling" book. You can find a free copy of this chapter on informIT

ps. Thanks to the other Odd-e people for their input!

 

History of Nokia Test


Everyone knows it! Nokia is *not* doing well. The new Windows strategy is not popular with the (geeky) public or Nokia employees. Recently, a couple of blog posts and comments have been posted about Scrum, Nokia and "The Nokia Test". I don't want to criticize the points made, though do want to correct the linkage between Nokia and the Nokia Test. Let me clarify.

I used to work at NokiaSiemens Networks (NSN) and, before that, at Nokia Networks (and before that at Nokia, but that is irrelevant for this post :P). In early 2000s, Nokia consisted of making phones (perhaps 75% of the company) and making telecom infrastructure (perhaps 25%). They were still the same company, but within the company they were very very separated. In 2007, the Nokia Networks unit was merged with Siemens Networks to create a new company... NSN. This company is not Nokia or Siemens.

Nokia Networks was one of the early adopters of agile development and Scrum in Finland/Europe. I like to believe that it had quite an impact to the Scrum in Finland as they asked their partners to use Scrum, but that is irrelevant for this story. I was invited to 'lead' the Agile coaching team in Helsinki as I had agile development experiences (mainly xp). I accepted and moved from China to Finland (cold!) where we supported product groups that wanted to change their development to agile.

The adoption in Nokia Networks wasn't top-down as the coaching team was hidden in a centralized department and had no authority (good!). We visited different product groups who were experimenting with agile development and create one community. This made it seem like we quickly had a big adoption, but in fact, we only combined all the grass roots initiatives and made them visible. By doing this, we traveled throughout the company to visit different teams who said they were doing "iterative" or "agile" or "scrum" or "xp". But we quickly noticed something interesting...

Most of the time, when we visited a product, they told us things like "we do iterative development, our last iteration was planned to be one year long, but it actually took two!" or, one of my favorites, "we do scrum, we are now in our 6th planning sprint". We, the coaching team, were getting frustrated with this as we were only a few and there were thousands of developers, who should we support? At some point, we decided that going "deep" rather than "broad" was a good idea, that means, we worked with the product groups that were serious and make them into examples. All we needed to do was filter all the product groups that were not "too serious." I remember discussing this with Kati (my pair in Nokia Networks) and we together quickly created two slides, one saying "you are not doing iterative when" and one saying "you are not doing Scrum when". We added these slides to our introduction to agile material and agreed we would use it internally (in the coaching team) do decide which product groups are serious.

Perhaps a year later, Jens Ostergaard invited me to his course and talk a bit about Nokia Networks (not yet NSN at this point). I grabbed some slides including the "you are not doing iterative development when"-slide in the appendix. (the presentation was similar to this one). Jens liked it and mentioned the slide to Jeff Sutherland who started to use it himself and called it "The Nokia Test." We didn't think the slide was very special so, of course, we had no problem but were very surprised to discover that it  became popular. I guess that had something to do with its simplicity.
A couple years later, in NSN people asked us to ask what this "Nokia Test" was about. (I remember Kati, the co-creator, asking me about it!). Most people in NSN didn't know about the slide as it was mainly used by the coaching group and it wasn't used for product groups to self-evaluate them. A year later, people in Nokia started contacted me about what this Nokia Test was all about because people in Nokia had never heard about it.

A couple points related to this, Nokia and Nokia test:

  • The Nokia test ought to be called "The NSN test" as it wasn't created in Nokia
  • The Nokia test was *not* for products groups to evaluate themselves, but was a coaching tool
  • The Nokia test was not really a test, it was called "you are not iterative when"
  • Most of the early Scrum adoption was in NSN, not Nokia. Thus conclusions about Nokia and the Nokia test are very irrelevant.
  • AFAIK, most of Nokia Scrum implementation wasn't deep. On the developer level, they adopted Scrum, but they never made management changes that ought to happen in a good Scrum adoption.
Oh, an amusing final note. I never use the nokia test myself. I don't particularly like the scoring test that it morphed to. I consider tests like that not useful except for a very specific context (and the context was quickly checking the seriousness of an agile implementation)

 

C assert and unit tests


The last month, I've come across this issue several time, to my surprise (because it hasn't come up in the years before).

If you are wrapping tests around legacy code and the legacy code has a C-style assert in the production code, then what do you do? Do you write a test for it? If so, how? Do you delete it? Why?

C-Style assert

Lets first have a look what C-style assertions are and why they are there. Assert is used for expressing a state that is always true. An assert cannot fail, if it fails then there is a bug in the code. So, C-style assert should and cannot be used for error handling. If the error is possible, then proper return value or exception error handling should be used, but if the error is impossible then this can be ensured and documented by using a C-style assert.

An extremely silly example is:

int a = 5;
assert (a > 0);

If this would fail, it would be a bug in the compiler.

C-Style asserts often go together with design by contract. In design by contract, we design the pre-condition, post-condition and class invariant to be per definition true. If it isn't true, then there is a bug in the caller in the case of breaking a pre-condition, a bug in the supplier in the case of breaking a post-condition or in the class in the case of breaking a class invariant. C-Style assert can be used to document this by, in the case of pre-condition, putting asserts at the beginning of a function. For example:

void doBlah(int x)
{
   assert (x != 0);
   ...

So, this code reads that the doBlah can never be called with 0, if it does, then there is a bug in the function that calls doBlah.

Assert and unit tests

Oki, so now we know why the asserts are there, but how do you deal with them in unit tests?

Well.... you don't.

If we take the doBlah function above, we don't need to write a unit test for the doBlah to assert when x == 0. This is an impossible situation and it is not needed to test that. As said, assert is not error handling, it is error in programming :) You design (the contract) states that this is impossible and thus there is no need to test it.

Though, it ain't that easy. You do need to make sure the assert is really an assert. I often read code where the developer uses assert as a method for error handling (and he will regret that when the assert goes off in a production environment, though usually assert is commented out for production code). If assert is not assert, then you can delete it and add proper error handling.

Assert and test-driven code

Many years ago, I used to write a lot of asserts in my code. It was known as good style to make your contracts explicit. Today, I nearly never write an assert and tend to delete them from production code when I see them. Why?

First, I can't add the assert when I test-drive as it still is a line of code for which I don't have a test :) But that wouldn't be fair, as I *could* in theory test it (stub out the assert in the C-library). To better understand why I don't write them, we'll need to look at the purpose. An assert makes sure something can't happen and documents that. When test-driving code, we document how to use a piece of code in the tests. So, therefore the documentation aspect of tests causes the assert to be less useful. Also, the impossible situation often won't happen because I tested it, so I don't need to put the assert there.

So, what to do with C-Style asserts in existing code? I usually do either of these two things:

  • Leave them and use the information as documentation
  • Delete them, they clutter the code




 

Review of: "Kanban" by David Anderson


Review posted on amazon.com:


I was looking forward to David Anderson's book. While I wasn't enthusiastic about his previous book: Agile Management, I liked his new work and the balanced view on change he is promoting. It all made me curious.

I've not been disappointed. Kanban is a readable and balanced book which introduces the Kanban method of bringing improvement and change to organizations. It is well written (better than his previous book, IMHO) and well-argued with many cases from David's own experience and from other people in the growing Kanban community. It is and will probably stay the definitive reference for the SW Kanban method.

The book consists of four parts. The first part is a short introduction to the subject. The second part is called "benefits of Kanban," but it better describes its history (from David's perspective). The third part is more of less a description of the Kanban method itself (called "implementing Kanban") and the last part contains several background improvement theories which the reader ought to know about when implementing Kanban.

Part two is called "benefits of Kanban" and is more or less a history of how Kanban has evolved. Chapter three is what the author calls "the recipe of success" and its David's opinion on what you need to do in order to build good and predictable software. I didn't like this chapter too much as it had a "just do this and everything will be ok" tone which I also found in his previous book. Chapter 4 introduces the work David has been done at Microsoft and how he improved a team without changing the process but by managing the WIP, an interesting story. Chapter 5 described David's work at Corbis where he continued his earlier Microsoft experiences and extended (or actually created) SW Kanban.

Part three describes the different aspects of Kanban. It starts with analyzing the existing processes, visualize it and then decide the boundaries of what is inside the Kanban scope and what is considered the outside world. The "outside world" works with the Kanban team based on SLA and releases based on a steady cadence (chapter 8 and 9). From chapter 12 the book covers less known Kanban topics such as classes of service, different reporting, scaling and operational reviews. Chapter 15 is then the actual "implementing Kanban" that suggests how you can move forward and implement these ideas in practice.

Part four covers broadly said three different improvement models: Theory of Constraints, Lean, and Deming. Each chapter provides a minimum introduction into the subject and suggests the reader to use these different models for making the gradual improvements in their processes. Chapter 20, the last chapter, discusses handling obstacles that need to be resolved quickly in order to make improvements.

There were a couple of things I liked a lot about this book... and a couple of things I didn't like and disagreed with the author. One of the things I disagreed with was the hidden suggestion that the problem of building quality software has been a solved problem. I got this feeling from the way he mentions things like professional testers, CMMi as obvious and barely covers e.g. integration. The book contains very little (nothing) about the actual development of software. But, as this isn't the main topic of the book, it doesn't matter that much... The thing that did bothered me was the suggestion that all works flows sequentially and that one activity has one purpose. I got this feeling from the way e.g. analysis topics were handled or how the last chapters talked about an activity being waste or not... for example estimation. Though, I agree that estimation might/might not be waste, during the process of estimating there is often requirement discovery ongoing, which is very valuable. However the side-effect of activities wasn't covered well and, I felt, it was assume that activities have one purpose and flow sequentially. That said, it might not have been the author's intention and just my sensitivity to this.

Then, the things I liked a lot about the book. One thing I really liked is how David positioned Kanban not as a SW development method but as an incremental (evolutionary) improvement paradigm. This book definitively challenged my own assumptions about change and how change ought to happen. Kanban tries to avoid change resistance by not making the change, visualizing the current processes and then making the change obvious to the people involved. I do think it has some drawbacks, but definitively like the approach. This message isn't given at one particular point, but it is the common theme of the book and of the Kanban method. Well thought of and also... well written. Another things I liked about the book is how David constantly refers back to his own experiences. This is not a book that says "hey, I got an idea, lets try this", but its a book where the author reflects on his history (together with the reader) and uses that to explain how he got to certain conclusions. Well done.

All in all, this book will definitively be the standard reference for Kanban. I was thinking between a four and a five star rating. I decided to go with four stars for the couple of things I didn't like. Anyways, definitively recommended for anyone who wants to know more about SW Kanban.