Is a quote from Jeff Jarvis' book: "What Would Google Do". If you suddenly find yourself out of business because your competitors has changed the game, and are light-years ahead of you, it might be because you were too busy milking the cash cow in the gold mine.

Many Companies, IT and software companies included, was in the last happy pre-crisis decade  of crazy growth, very busy milking the Cash Cow in the Gold Mine. The poor beast is not giving so much milk now. And if one is looking up it is clear the world does not look the same as it did before.

many software companies find out, that they completely missed being aware of the costs of running a software business. When the order-book was full,  the dedicated work of doing things better, lowering cost and improving quality was not on the agenda. Hire more staff (if you can them) and cut corners whereever possible,  was the practice of the day.

In the software industry as well as construction industry, the number of poor-quality, too late and too expensive projects grew rapidly. The only difference between construction and Software is, that in construction you always end up using what has been built, and thus getting some value out of the investment. Sadly that is not true for all software projects.

In the meantime a cost effective outsourcing industry has grown up, to do much of the work domestic companies used to do. A even larget threat to the worn out Cash Cows is that lots of, what used to be, expensive software solutions are available for free or very cheap on the internet. Google (here they are again) has created a strong competitor to Microsoft's Cash Cow: Microsoft Office Soute. While Microsoft was busy milking it, Google solved the real problem about real-time collaboration, sharing and version control. This will forever change the landscape of office applications, and Microsoft is way behind (as is Open Office and all the others still on the old paradigm).

I  was recently looking for software for doing on-line surveys. My search led me, among others, to these two companies: 2ask and Survey Monkey. My theory is that 2ask has been busy milking their cash cow (hopefully so), while Survey Monkey changed the business. For a tenth of the price Survey Monkey offers a fancy, slick application that allows you to build your own surveys very easily. Take a look for yourself, who do you want to buy from?

So what are you doing? Spending the time trying to get the old cow to give more milk, doing more of the same, of are you taking the opportunity to discover what business you really are in (another quote from WWGD), and finding ways to do that in a low-cost way?

And in our own kind business there has also been cash cows: Scrum certification classes (we do not do those) with long waiting lists and customers being willing to believe that standing up i a  circle 10 minutes every day would solve all problems. Maybe it is time to rethink that business too?

By Bent Jensen

I first came across the term vertical slice when I was in the video games industry. Trying to raise capital for our game, we were told by venture capitalists that they needed to see a vertical slice in order to assess our concept. That meant a small version of our game with just a little bit of everything. You should be able to see the technology, the artwork, audio, game design and all. I am not sure where the term originates from, but it is easy to realize what it means. If you consider a product to be composed of layers, the vertical slice represents a little bit of each layer.
This blog is called The Vertical Slice for a reason. While there is great focus on prioritizing in agile development, the emphasis is often in the concept of "business value". Which is a very sound focus compared to say, premature optimization or writing a system that is unnecessarily generic. However, focusing on vertical slices is equally important. As my colleague Lars suggested recently, the term breadth-first development is perhaps even more descriptive. If you consider the product to be a tree of increasingly detailed features, you want to start at the top and move into the details at all levels at the same time.
There is a consequence to this: you run into a lot of problems at the very start. A project that we are currently working with includes a web-frontend, a database layer and a reporting system that have all given us different kinds of problems. Other teams might have focused on getting one part working before moving on to the others but in the spirit of breadth-first, we wanted to work a little bit with all of them. That way, we don't run off on tangents in one of the layers, which might turn out to be unfeasible or simply incompatible with the rest of the environment.

By Kristian Dupont

Some interesting new tools in the field of continuous integration and code analytics are getting to speed and are exceeding past the old first-movers.
Two such tools are the build server Hudson and the “Code quality management platform” of Sonar. The first gives you a very quick to install and get running build server, with a very inviting and intuitive user interface and an open platform for third party plugins. Forget the dinosaurish CruiseControl (for Java at least) as the open source build server, Hudson serves you way better.
Your development team will love the excellent dashboard with sunshine and clouds showing how your projects are doing, and the metrics graphs with history of build and test results, build times, tasks etc. In terms of “smartness” it is said to read your Maven pom.xml and ensure that dependent builds are ran in the correct order (still need to try that).



Sonar joins a number of open source code analytics tools and puts it into a nice but at bit over cluttered dashboard. Look here to see a Sonar site of the Apache frameworks. I just want to show one of the features which I find most useful, the coverage cloud:



It identifies the classes probably needing an extra look, because complexity is running high and code coverage are running low. Brilliant way of visualizing code quality.

But remember: one thing is to know the state of your code –  another is to act wisely on it. Code coverage derived from automated test suites does not tell you, if you have assertions in your unit test. Without assertions you can add and delete code without test failing.
The violations of code quality rules and the complexity measures of you components, does not tell you if your design is thought out well, or express the domain your trying to support, only a combined effort of analysis with your customer and experiments can reveal this for you. But on the of path of getting less variation in code and fewer defects – that this getting closer to software nirvana – I will not be without Hudson and Sonar giving me daily updates on how we are doing.
By Jesper Thaning

I'm reading Dr. W. Edwards Deming's main work Out of the Crisis for the first time and thought I would share some of Dr. Demings wise words with you. I didn't really expect it but Dr. Deming actually has something to say about software development.

Earlier this year I had the pleasure of reading his other main work The New Economics and was amazed by the insights of Dr. Deming and how little people in general and management in particular have understood what he actually said. Granted, his overall style could easily be termed idiosyncratic and collage-like but stunningly concise formulations are spread all over.

This is what Dr. Deming said about the "supposition that it is only necessary to meet specifications" when it comes to software development:

"A programmer has a similar problem. She learns, after she finishes the job, that she programmed very well the specifications as delivered to her, but that they were deficient. If she had only known the purpose of the program, she could have done it right for the purpose, even though the specifications were deficient."

That's it! Did I mention that Dr. Deming wrote this in 1984, long before anyone talked about Agile software development?

By Thomas Blomseth

Some thoughts that popped up on my first day of attending our Poppendieck course on 23th of June.

Knowledge inventory

The concept of “Zero Inventory” is not desirable and in fact does not hold in Toyota (go to the production plant and notice the trucks on the park yard outside the factory with inventory waiting to load it into the factory – the drivers are sleeping some times), its all about having the correct amount of inventory.
So! Mary keeps a log book containing what programs she installed on her laptop and what problems she experienced (hope she doesn't mind me telling this in public). When there is a problem on the laptop, she goes to look into the log book instead of googling it again spending time on finding the same site as 6 months ago, wasting time on finding already acquired knowledge – relearning, which is waste.  
Well. This log book is knowledge inventory. Knowledge that we keep close to us, ready to use, but it takes up space and the more we have, the more difficult it is to find the knowledge we need. In software we do not have physical inventory, like wheels ready put on a car in a car factory plant, but we have knowledge inventory. So how do we produce the correct amount of knowledge inventory?

Knowledge briefs

Lets go to the source. When we make knowledge and put it into our repository (perhaps a wiki), we should make the knowledge condense, then it is easier to find - and use. But it is difficult to make knowledge brief! If I make a four page documentation of a feature, and come back six months later, I will spend time  

Because knowledge in wikis are knowledge inventory, and tend to grow and grow. Too much get a burden, you cannot find things and when you find a document, its four pages long and the valuable knowledge is hidden in a lot of irrelevant noise. (Can search engines solve the problem of finding useful knowledge in a split second on the internet? I don't think so.)

So what about a wiki that have limited space? You can only put 2400 characters on a page, because if you put on more, you build up too much knowledge inventory. “If you cannot fit your knowledge into an A3, use an A4”. Constrain yourself to condense it even more – extract the important parts e.g. the exceptions in the business case that you only found out about later, and spent time on trying to grasp.  

I want to make an exercise on our next workshop to practice the art of making knowledge brief, to avoid building up knowledge inventory.
And last thoughts: Are knowledge always written? Can you build condensed knowledge in pictures and graphs?

By Jesper Thaning

At this time of year we are constantly tempted to borrow money for spending more for Christmas. Money-lenders offer us one-click-loan on the internet or even so called SMS- loans on the mobile and shops are trying to persuade us with “buy now – do not pay until March” offers.

Most of us do not fall for the temptation. We may have tried it once, and know that after the short pleasure of being able to spend, comes the long pay-back period, where our freedom are much more limited than it otherwise would be.

When it comes to software development, we are also at times confronted with the same kind of temptation, especially close to some kind of deadline.  We may not be completely finished with what we should do, and when looking for a way out, we may think why not borrow a little?

There are many ways to borrow in developing software; generally we do it by lowering the bar a little and not doing things exactly as they should be done. We may create a solution that does not cover all required usages, we may make a shortcut  we know will cause us a performance penalty later or we may simply skip some of the testing we normally know to be good engineering practice. In this way we create technical debt in our product. Unfinished work your organization owes your product, as Preston Smith defines it in his book “Flexible Product Development”

Those who have tried to ship a software-product know this temptation. Most of us have fallen for it, at least once.  We also know how painful paying back is. The really strange thing is that many software developers and even more  software managers apparently does not learn from that experience.

If we stretch the Christmas analogy a little further, one of the things that are different with technical loans in the software, is that we do not know exactly when payback is due. There is no guarantee that you can wait until after Christmas, in this case the deadline. Some of the shortcuts you have taken may come back to you, at the most unpleasant time, where you thought, that now you were going to ship.  Also you do not know the interest rate – the only thing you know from experience is that it is high. Almost always higher than you expect. The cost of fixing a problem after the software has been delivered to customers is sizes of magnitude larger, than what is was, when you decided to take the loan.

It may very well even be so, that you never will be able to pay back in full.  You may for the life of the system, be paying the interest, which is a larger than necessary cost on future development,  and never have the surplus to actually be able to start reducing the debt.

If investors or buyers are smart when looking at your company, they will look at the size of the technical debt, with the same scrutiny as they use when examining  the financial data, since they know that a large technical debt, may mean that what looks like a promising company, actually is more like a sinking wreck,  only able to stay floating with a tremendous effort and thus with little potential for growth and future profits.

By Bent Jensen

Making a piece of software more generic is tempting to programmers. But it isn't free.



I have noticed something about the way I think. Whenever I think of a solution to a given problem, my mind starts wandering off looking for a more general solution that will fit a more general version of the problem.
I enjoy this feeling, it is intellectually challenging. I consider myself a decent programmer and I think that to some degree, this habit is either the cause of or an effect of this fact. Talented programmers have the ability to redefine problems - in more general terms and in particular, in simpler terms. There is always a better and more generic solution which is almost always more interesting to create and possibly a good investment as well. But tempting as it may be, there is a cost and it is something that I need to remind myself of frequently.

I was recently working for a customer that had a very large database of clients. At one point, they needed a list of clients that matched a certain number of criteria's. A simple (well it was quite complex but still) SQL query, and I would be done. Simply handing them the output would be the least generic solution to the problem. However, I asked whether this was something that was likely to show up again and it turned out that it was. So I hacked a minimalist winforms app that could perform the query. And because they might need to fetch old data, I made a date picker on the form, allowing them to choose when the data should be from. A little more generic and a wise investment. I spent about ½ hour making this app and I am sure that this ½ hour would quickly be spent by me or somebody else real soon. But I could have made it more generic (and indeed, I did consider this). It could be customizable in all kinds of ways, applying arbitrary filters, outputting in various formats and so forth. If one extreme is the hard data, the other, I think, is Turing completeness - where you have a programming language that gives you all the possibilities that the computer offers.



So besides from the fact that making something more generic takes more time, are there any drawbacks? Surely, more generic == better, right? Well, I once wrote a blog entry entitled "Good things about hard coding". This was obviously meant in a bit of a provocative manner but my point was and is that there is a cognitive cost to generic code as well as an economic.

Quick, tell me, what does a FilterItem do?

Say that you are making a program that needs to manipulate some data that comes from a file. You may then have a FileReader class which reads your file and deserializes the data. Good. But then you figure out that this data might as well come from a database. So you make an abstraction called DataProvider, of which FileReader becomes a specialized version. It's beautiful and generic. However, if I look at the code now and I am not the author, the term DataProvider is a little more abstract than FileReader would be. I can sort'a tell what it does but where as the term FileReader is quite self documenting, the more abstract term DataProvider is a little less obvious. And the more layers of abstraction that you apply, the vaguer the self-documenting effect becomes. You end up with functions and classes that are named with combinations of terms like stream, container, input, output etc.
In my opinion, you should strive for generic code, but only to the point where it actually saves you from duplicated code. The way I try to achieve this is by constantly making vertical slices, or breadth-first development - moving to the right on the genericity scale every time I spot duplicated code.

By Kristian Dupont

How do you define quality in a software product? Few defects, no crashes, happy customers?

I believe that software quality really comes down to a few metrics. One is the amount of defects that makes it out of your lab. Another is your ability to maintain the product throughout its life cycle.

The bug metric is one I think most people in the software industry would agree on. So one might ask, why are we still creating them in high volume? Are we really at a point where it is not feasible to lower the rate at which we introduce bugs? I hardly think so. I think developers need a change of attitude towards bugs.

I like to tell myself that for every bug I pass down the "software assembly line" to the testers, I am responsible for the time they waste on finding, reproducing and reporting this bug. Or even worse, if they don't find it I will be responsible for wasting my customers' time.

In case the testers actually find my bug I am furthermore responsible for delaying the entire feature by introducing a need for a "bug fixing phase" where I will be debugging issues that should never have made it into the code.

If I introduce multiple bugs I will most likely also be responsible for wasting somebody else's time on prioritizing them.

I think most developers know that the total cost imposed by defects, rises exponentially over time. But what is really important, is that developers need to accept that they are the key to introducting less bugs, and managers need to accept that trying to push developers to deliver features faster is not going to lower the defect-introduction rate.

What do you think?

By Sune Gynthersen