Tech Trained Monkey

Everyday Problem Solvers

Tag Archives: methodology

Analysing success

As the 1940’s air war in Europe intensified, the Allies faced a major problem. Their bombers would leave England by the hundreds, but too many of them didn’t return, brought down by extremely heavy enemy flak. The Allies desperately needed to beef up the armor on their planes to provide protection, but armoring an entire plane, or even an entire cockpit, involved far too much weight. How could they choose the few especially vulnerable places to be armored?

A couple of clever engineers solved this problem with a counter-intuitive analysis. After comprehensively logging the locations of flak damage inflicted around the fuselages, engines, and cockpits of planes returning from hundreds of bombing runs, they calculated Read more of this post

Why english

As you know (or not) I’m Brazilian. I was born in Brazil, studied in Brazil, I work in Brazil, and (I’m ashamed to say) never been to a English speaking country. Nevertheless my blog is written in English and more often than not I hear the question “Why English? Why not Portuguese?” and I my answer always is “Because I want to reach as many people as possible”. Reaching people is not why I write this blog (my motives are strictly selfish) but it’s the motive why I do it in English.

I also program in English. When people ask me why I reply: Read more of this post

The “build me a pair of pants” Problem

For a long time ive been hearing about scrum and agile methods and what i like to call “deliver piece by piece” methodologies… and ive been also studying it (my boss seems to like it… joking… i was courious about how this “magic” works…) and i must say its quite… … … un-rational in my opinion. I cant get pass the fact that 1. The client will decide what i will build in which order and 2. If i was the client i would actually buy a shotgun, and unload it with mighty wrath, when someone come to and try to convince me that “paperwork” is a deliverable. Clients buy Solutions/Products, or promises of such. Nobody buys a project (I will talk about outsourcing another day). To express what i mean i came up with the “Build me a pair of pants”, as it goes like this:

A costumer come to you and say that he/she needs a single solution for 2 problems: “the too many items in the hands” problem and the “im feeling cold im my legs”. As you look at the situation you notice that hes/shes out of pants (ill leave to your imagination other details that are not relevant)… the answer is clear: He/She need pants. The pockets will solve the hands availability issue and the jeans will solve the cold issue… right? You decided that, as always, scrum will be applied. So you build the log and it consists of 2 items, build pockets and build the legs. As a good “master” you ask the client which one he wants first, and as a client with no pants on he answers: “i dont care, i have my hands full and im feeling cold in my legs!” so, the question lies here: which one you build first? The pockets or the pants?

If you build the pants first, ok you finish the cold issue… but how does he gonna put on the pants? “hands full” issue blocks it… and lets say, that ok, he put everything down and got into the pants somehow, when the pockets are ready, you will force him to stop again, drop everything, “attach” the pockets and ok lets go on? OR youll build the pockets, dont solve any problems (he now carries pockets on the hands) and make him stop only once and attach the pockets on the legs, put them on and move on?
The main problem is yet to come: You may not realize, but when you deliver “piece-by-piece” software you abdicate the “OMG moment”. When you deliver part number 1, he might be gratefull (notice the might) but he will focus on what he doesn’t have… yes, clients are glass half-empty kind of people. And when he get the last part, he will be used to the other parts, and therefore “no wow for old-news” comes in and slap you in the face.
What is the “right” way to do it then? you might be asking… Get a “closed-scope” contract, assume risks and charge a bit more to compensate? What most people fail to understand is that when you sell a “software project” your actually building a product specifically to one client, at least, and that the client you pay you for the product! not the project! the client could not care less about your methodology, internal documentation (they do recognize the value of user manuals, and training material and a few others) or other any other crap (DISCLAIMER: clients attorneys might think differently about that). Stop thinking project and start thinking product. Don’t listen to the sales people. Great products do a lot more revenue than great projects, and great products are not necessarily the result of a great project. Actually as far as I can remember, the greatest products in the world are the result of a mega-failed project (think space shuttle program: 150 billion cost overhead, Sydney Opera House 14x: cost overhead and over 10 years delay, and trust me there are a lot more).
i really don’t want to end this post with a statement or something… i would like to hear back…