Partly done – root of evil

Now, I’m not religious, but if I thought there would be a devil in software development his name would be Partley Don Woork. Do you know him? Shining on the surface? Nice smile? Cute outfit? But completely worthless when it comes to some serious work. And when there’s a problem, he just starts babbling and you have no idea of what he’s talking about. Don’t invite that S.O.B in your house!

A bad manager does not recognize Partley, or he think’s he’s a rather nice guy. Good to bring with him to customers for demonstrations and sales discussions. But all who have to work with the client after the sale is completed knows that the customers soon recognize Partley too. And they don’t like him either.

A good manager knows that Partley is not worth the applauds on a sales demonstration. He knows that even if he can get two Partley’s for the same price as one Completely Don Work, he knows there is a reason for Completely being so expensive in the beginning. He saves the cost by just cutting away all those expensive meetings where the behavior of all those Partley’s are being discussed.

The management for our software development department is now successfully working against all those Partley’s, and it shows. Not only does it show in the quality of the software, it shows in the actual value being produced. And perhaps most importantly; it shows in the pride of the people at the department. Having to work with Partley’s is bad for workman’s pride. And manager’s helping teams fight Partley boosts the productivity! Try it: there is a world with less Partley’s if we all work against him.

Nice to have! Or not…

The purpose of software development should be increase the product value, in other words make it more useful and worth more to stakeholders. But in the urge to improve and to increase the number of features causes, as I guess everyone knows, usability problems. Microsoft Office is a typical example of this. Microsoft has struggled since the early 1990’s to get a decent UI for all these features that probably just a minority of the users really wants. Besides the problems with including these nice to have that a minority wants is that time is spent on this, instead of what people really need. In other words, a system can be very complicated and complex without solving the user’s problem.

An example of this was when a customer had a system with a very complex state machine. The users struggled with it, it created problems testing the system (since all the states needed testing in all clients and for all situations). When looking at the previous version, I could see that the state machine was very simple, so I asked why they’d made it so complicated. The reason was that they wanted to support that customer’s signed an order before invoicing, so the customer knew what they would be billed in advance. But  this is not possible with the current state machine. They’d spent all that money, made the system too complex for users and coming development and testing and the thing would still not do what the customer really wanted.

The picture below is worth thought:

Source: Windows Mobile – No Secret