Kallokain

Lately, I have had reason to study the effects that Design-In-Process, DIP, has on the profitability of software projects. It turns out DIP is a project killer, and potentially a corporate business killer too. What is Design-In-Process? It is partially finished work. Most software development projects have too much of it. The manufacturing industry learned decades ago that too much inventory was a bad thing. In the software development business, the inventory is Design-In-Process. We still haven't learned the lesson. Why is DIP bad? Let's have a look at the classic Return On Investment (ROI) equation: ROI = (T - OE) / I Where: ROI is the Return On Investment, a measure of how profitable a business system (company, project, etc.) is T is Throughput, the amount of money made OE is Operating Expenses, the money the business system spends producing throughput. Wages, rent, electricity, are all OE. I is investment, the money tied up in the system. This includes computers...

While looking for material about queue theory, I came across a traffic simulator that is worth a look. With it, you can simulate how traffic moves, and doesn't move, in different kinds of situations. It is worth a look.

I have begun working in a new project recently. It is the first Scrum project at Wireless Car, and they hired Tobias Fors from Citerus to get us started. Tobias presented Scrum in a manner that was both entertaining and informative. The kick-off took two days. The first day was a Scrum presentation, the second day we did Sprint planning. It is rare to meet someone that can talk about the same subject matter for two days straight without being boring even once. I usually make people's eyes glaze over within a few minutes, so I was very impressed with Tobias. Also, for two days I had someone new to talk about agile and TOC and queue theory with. Great!

I missed the first Gothenburg Ruby User Group (GRUG) meeting, but not the second, last Thursaday evening. 15 geeks (only a few of whom are shown in the picture), and Ruby. Doesn't get much better. Niclas Nilsson and Karl-Johan Kihlbom talked about the recent RailsConf conference in London. The main event, arranged by Emily Bache, was a code kata. You can read more about it in the GRUG Google Group at http://groups.google.com/group/grug . The next meeting will be in a month or so. I'm looking forward to it already.

I have written a presentation comparing flow organizations and functional organizations. You can check it out here if you are interested in this sort of thing.

In the Systems Thinking series of posts (also including Systems Archetype: Shifting the Burden and Systems Archetype: Shifting the Burden to the Intervenor ), I try to show the basics of how complex business systems interact. With the systems archetypes, it is possible to find standard solutions to common problems, but there is still a piece missing. In a specific case, how do you find the root cause to your problem? Have you ever worked in a project, or workplace, where it feels as if you are spending all your time fighting little fires? Usually, all those little fires stem from a few root causes. Unless you want to spend your time fire-fighting, you had better find the root cause of your problems, and deal with that. There are many methods of finding root causes. One of my favorites, because it is so simple, is Toyota's Five-Why method. The idea is that when you are faced with a problem, you ask why that problem occurred. When you find the thing that caused your problem, you as...

So, maybe it's not a full month. Then again, I'm not really back. I am writing this in an Internet cafe in Ho Chi Minh City, Vietnam. If you want to study one-piece-flow, and want to see why moving small batches around is better than lugging large ones, HCMC is the perfect place. The streets here have more traffic than anything I've ever seen. There are very few traffic lights, and driving on the right side of the road is sort of a very loose agreement. Also, the most common vehicles are scooters and light motorcycles. There are 30 million scooters in Vietnam, and by the look of it, most of them drive by my hotel each day. (I'll upload some pictures when I get back.) One would expect the result to be total chaos and confusion. It isn't! Actually, the traffic flows like nothing you've ever seen (unless you've been here, of course). There are two reasons for this. The first is that though the streets are packed with vehicles, each vehicle is small and manouver...

I'm taking a month off from blogging. Will be back in September.

There is a special case of Shifting the Burden which I am especially familiar with because I have worked as a consultant for many years: Shifting the Burden to the Intervenor . Description The problem may occur when an organization decides to rely on outside competence to solve an internal problem. The problem may be solved. The catch is that the competence to deal with the internal problem now resides outside the organization. This makes the organization vulnerable if the problem occurs again. "The organization" may be a company that outsources development work to a consultant, or outsources a part of their infrastructure to a subcontractor. Departments within an organization are also vulnerable. They may (not always voluntarily) let another part of the organization take over an important function, only to find that the other part of the organization is not able to process requests quickly (usually because of queues), may not fully understand the requests (development depar...

Description Shifting the Burden is one of the more common systems archetypes. The problem occurs when a short term fix is applied without regards for possible side effects. The short term fix seems to work, but over time the side effects escalate. In many cases, the capability to apply a long term solution atrophy over time, making it very hard to correct the problem. Example A classic Shifting the Burden example in software development is when management tries to apply a brute force solution, like increasing the manpower of a project, or forcing developers to work an excessive amount of overtime, to compensate for low productivity, or poor planning. The diagram above describes a situation where a project has productivity problems. In other words, it won't make the deadline. The obvious, but often flawed, solution is to add more people to the project. Most projects measure progress in terms of hours worked. Unless you live on Mars, you are almost certainly familiar with the basic ...

Systems thinking is a theory that argues that social systems must be studied as a whole. It is impossible to predict the effects of the whole system by studying its parts in isolation. A "social system" can be anything from a family unit, to a system of interacting economic units (companies, countries, etc.), or even an ecological system. Systems thinking is an important part of the theoretical foundation for agile software development methodologies. I got interested in it some years ago because I kept stumbling on references to the systems thinking bible, The Fifth Discipline , by Peter M. Senge, in books about agile methodologies. Somehow, there was always one more programming book to buy first, but then I spied a copy at my parents-in-law's house, and borrowed it. After a few pages, I was hooked. Since then, I have worked systems thinking into the way I work. I have found it to be a valuable tool when trying to figure out what is really happening in different situation...

A while ago (in another company than the one I work for now) I worked for a company that did not believe in making things easy for their developers. Everyone had to work in an open landscape. The landscape was divided into rectangular cells. Developers sat at corner desks, so that developers in a cell faced away from each other. To make communication between developers even more difficult, people working on the same project were usually located in different cells. A new and very complicated project began. We developers realized that the seating arrangements would never work. There was no way we could succeed if we could not talk to each other. We decided to ask our department manager for a project room of our own. The department manager realized that we needed to work close by to have the slightest chance of success. "OK," he said, "you'll get the room, for this project, because it is an unusually difficult one, but of course you can't get one every time you need...

A couple of people have emailed me about missing images and animations in my Variance Trap series of postings. The broken links were due to a reorganization of my web site. I have finally fixed the problem. You can view the postings here: Part 1 , Part 2 , Part 3 , Part 4 , Part 5 .

Apress has listed a new Ruby book, Pro Ruby , among its forthcoming titles. Pro Ruby shows how to combine Ruby and agile methodologies into a unified, powerful package. I do have a special interest in this book, because I'm writing it. (Which is why I have blogged less than usual lately.) I don't want to give anything away prematurely, but I can tell you two things about the book: It does not have a Hello World example There is a sample application, but it isn't an online shopping application There will be some time before Pro Ruby hits the book stores. When it does, I hope you like it.

This site is too good to miss: http://thedailywtf.com/

You know all about the Agile Manifesto , of course, but what is the Declaration of Interdependence ? It is the next logical step, the answer to the question how Agile principles can be extended to non-software projects, and management in general. Alistair Cockburn has written about it on his site , and in an article for Better Software Magazine. The declaration is a year and a half old, but the article was published in June. Do read the article. It does show how profoundly different an Agile business is from the ordinary kind. (Technically, "the ordinary kind" is a business based on the principles of Scientific Management and cost accounting .) Just a little something to show that the blog is alive. Have been quite busy the past few weeks, but will make time for more blogging. (I am not sure if that is a threat or a promise.)

I had some good news a couple of days ago, and I just can't resist toting my own horn a little. A couple of years ago I was subcontracted to write a web based print formatting system. The system could automatically produce brochures, and used FrameMaker as a formatting engine. I haven't counted this system as one of the great successes of my career. FrameMaker and Internet Information server did not play well together. (Neither did Apache and FrameMaker.) In the end, I solved the problem by writing a small web server of my own. Though the solution worked, my client was not happy with the design. He insisted he wanted the application to run under IIS, even though it was not technically possible. Fortunately my client's client did accept the solution. Still, my client wasn't happy, so I wasn't happy. Earlier this week a friend of mine told me what became of my 'failed' system. The system has worked very well for more than five years now. The customer estimates...

A friend and I spent an enjoyable afternoon debugging a Rails application yesterday. "Enjoyable" and "debugging" usually don't go together, but in this case they did. My friend, who happens to be a much better programmer than I am, was stuck on a bug. His application had a form that worked correctly the first time it was used. The second time around, values filled in the first time reappeared in the form. In the end it turned out that an automatically generated find_xxx_by_id method returned the wrong data the second time it was called. (My friend is filing a bug report.) Our excursion into bug country was enjoyable because we solved the problem as a team. It made it easier to keep focused. There was communication. We could bounce ideas off each other. I learned a few new things about ActiveRecord. We solved the problem, and the bug report may save other people some trouble in the future. It was a good half days work.

The connection to www.henrikmartensson.org is incredibly slow at the moment. Don't know why. My site host and I will look into it.

Avoid method name collisions by mixing in modules to an instance of an inner class. class Outer class Inner end def initialize(mixin) @inner = Inner.new() @inner.extend(mixin) end ... end When extending objects with mixin modules, there is a risk of method name collisions. Given the example in the Module Injection post , the execute_before and execute_after methods in the Strategy object might collide with method names in a rule module. Suppose the rule module looks like this: module TransformationRules def functiondef_before(element) ... end def functiondef_after(element) ... end def execute_before(element) ... end def execute_after(element) ... end end When the dispatch mechanism in the Strategy object finds an execute element, it will dispatch the element to the wrong execute method. It will call the execute_before method defined in Strategy, not the one defined in the TransformationRules module. Pollution Control reduces the ...