Tuesday, October 03, 2006
Anyway. It is at the same time I see many people turning away from a Big Design Up Front, plan-based methodologies or (at the other side of the spectrum) from working without any formal method at all. Both have in common that they have an urgent need to get a better grip on the (planning of) the development process, and it is likely they will meet each other somewhere 'in the middle' where the agile methodologies are.
It's funny to notice that getting started with agile methodologies in itself also is best done in an agile way. With that I mean starting with a minimal set and from there, discover where and when you need to scale up. But although you start with a minimal set it still is important you are aware of which direction you want to go. It is even more important to ensure that the people that will be doing the actual work, agree this is the direction you all want to go. Otherwise the risk of resistance up to a level where you will fail misserably will be unacceptable high.
For that reason many of the techniques I suggest to introduce into the development proces, I actually use for introducing the techniques themselves. Like a meta-method if you will. Depending on what I think would fit, this could be using the MoSCoW principle for prioritization the changes. But also make them aware of the similarities between the Onsite Customer practice and them being involved in changing the development process.
This has many advantages. The most important ones are that I verify early in the process if people actually understand the technique and if it will work for them. While doing so I have the opportunity to use a kind of trial and error way of implementing a technique, and securing it not only in a formal way but also by creating enough support for it to last after I have left the building.
Monday, September 25, 2006
What was the case? I was just about to move in two weeks and still had a lot of things to do. One of them visiting a SOA Suite 'code camp' in Slovakia on which I was to present about Oracle Business Rules, and I still needed to prepare myself. But at the same time many things needed to be done privately to prepare for the move. I already had some extremely busy weeks before, so I saw going to Slovakia as an opportunity to escape and get some rest before the move itself. And boy, what a mistake that was.
As always it started with too many things to do in too little time. We have a parquet floor in our new house that looked so dull that I nearly fell asleep only by looking at it. So we decided that it needed a different colour. But also the ceiling, walls, casing, etc needed to be repainted. I hoped that during my stay in Slovakia the painting could be done and the floor soured. Painting alone would have taken two weeks the least when I would have done it myself, but as my brother in law was doing it and since he is a professional I hoped for some magic here.
And magic he did, but when I got back on Friday the floor still needed to be soured. I hoped (but was not really expecting) to be able to sour and clean in one day. Two of my best friends helped me out on Saturday, but on Sunday I was on my own. And despite my best efforts it took me until Monday before souring was finished and then I still had to clean, paint and enamel. So despite the fact I was supposed to go to the office I was pushing myself to the limit while trying to get the floor to the stage that it was painted, working for eight hours in a row, no rest except for a quick coffee.
I had to compensate Tuesday evening to get some urgent work done, so on Wednesday I still had not packed even one cardboard box. And what a contrast that was with my original planning that assumed that I would start packing somewhere during the Sunday! As a result I had one Wednesday evening and one Thursday left to pack before Friday, which was the day the remover would come. And I only had that Thursday because I could switch it with Friday, which originally was my day off.
So what you then do is stop thinking, start packing like a madman, and see how far you get. And at 01:00 we were almost done! But not quite, so when the remover came at 9:00 it was an utter chaos in our old house, and a couple of boxes were carried away while I was still packing them. There was only a small comfort in hearing that the removers were used to this because they saw this happening all the time. Despite my wife pledging me not to do so, I had to leave at 11:00 to the office. Later on my wife told me that that was the moment she knew for sure she was married to a lunatic.
Now what has this all to do with time boxing and prioritization? Everything! It perfectly illustrates the situation that we encounter very often being a customer wanting every requirement to be implemented, which in theory makes time-boxing using the MoSCoW principle and leave out Should Haves if they don’t fit anymore in the time-box (when there is a temporary work-around) almost impossible. In my case the requirement was that everything should be packed before the removers would come. The time-box is obvious: Friday 9:00 the removers are there, period.
However, no matter what kind of customer you have in practice MoSCoW can at least be used to determine a best order in which things should be done, doing the most important things with the biggest risks first. In my case that was preparing big and heavy things for removal, like securing the washing machine. I got that done. And even though customers say they want every requirement implemented, when no time or budget is left they suddenly are capable of making compromises and drop Should Haves like they couldn't care less. Just like that. In my case the compromise was that the removers left enough stuff behind so that I needed to drive myself two more times to get the old house empty as a work-around.
Maybe some next time I will tell you about the similarities between something that all people understand, being that you don’t leave your garbage to the new owners of your old house, and the principle of refactoring, which only a few software developers seem to understand.
Wednesday, September 06, 2006
You don't even need to watch carefully to discover that often two people that seem to be talking about the same, in fact could not be further from that. "Tell me something new", you might react. And you're right, I'm not telling something new, it happens all the time. And that is the saddest thing in my business, because it costs us all a huge amount of time, money and frustration.
Knowing all this it always amazes me how apathetic we seem to be about it, because it is so easy to do something about it. Try asking people what exactly it is they mean when they tell you something, that's all. Simple enough, wouldn't you say?
The other day I had a conversation with someone about preventing overrun on activities, and he said he was using the time boxing principle for that. But from the rest of the story it became clear that there still was a considerable track record of deadlines not being made. And as always the problem was that the customer kept on adding new requirements during the project and was not able to prioritize them properly, naturally. Now where have I heard that story before?
So I simply asked this guy what he meant with this "time boxing" principle. Well, not exactly like that, I must admit. In practice it is not always as that simple as that because before you know it people get the impression you think they are stupid or something. Or even worse they start to think that you are stupid, and you don't want that, do you? So what I asked instead was how they had implemented this "time boxing" principle. Do you notice how different the question is, but that in principle I ask the same?
And what he told me is that they had divided the functionality into smaller pieces that, on an average, could be implemented in a couple of weeks and that they had set a final delivery date for every piece of functionality to deliver. Plain and simple, right? "So what happens when you find out that something takes more time than anticipated?", I asked. "Well, we have planned for contingency, of course", was the reply. "And what if they customer finds out that the specifications are not complete?". "Well we create a change request for every extra thing they want and see if we can implement it in the time box. Otherwise we postpone it to the next time box or, if they really, really need it, increase the scope and set a new end date. But that will cost them, of course". "Have you ever hear of the MoSCoW principle?", I asked. "Huh?".
So what I found out with this simple question, is that the time boxing principle had been implemented only poorly, because they were not applying a proper prioritizing principle, which coincidentally will make time boxing fail without.
I'm not going to explain here what time boxing and the MoSCoW principle are all about. You can easily find out elsewhere. And I'm also not going to tell you that using them is as easy as it sounds, because it's not. Maybe some other time I will tell you what you can try to do about that. I will also not explain here that normally you don't plan for contingency when you do time boxing and what a waste of time making change request forms is in that case.
But I do hope I gave you an example how asking simple questions can help you in
preventing people from wasting each others and especially your precious time.
Wednesday, August 30, 2006
I confess, I made a bad mistake some time ago. I started to work on a project that had no proper source control system in place. Instead, zip files with source code were copied back and forth and merging was done manually using WinMerge. And I did not take a stand and say: "I want a source control system or I'm outta here!". Not that it would have helped, but it is the principle that counts.
As a result I spent at least two hours every week merging code. And then the risk that something would go wrong and I would need to spend at least another hour to find out what was going on and correct the problem! As I have the memory of a gold fish (*) those were the two hours I picked up the phone saying "I call you back!" only to put it down without taking the effort to notice who was calling. People could have said my boss was standing outside giving free money to whoever asked for it without me hearing them, let alone being interested. By Turing, what a stress!
Now I'm in a similar project situation where we do use a proper source control system, in this case Subversion. If they are using a source control system in Heaven, I'm sure it is Subversion. Although not flawless, but what a blessing it is! But if you are using CVS, that's OK too. And there are probably more cool source control systems that I don't know of, but since I don't know them, who cares.
By the way, did I already tell you I wrote a white paper about how to use CVS in combination with JDeveloper? No? OK, I wrote a white paper about how to use CVS in combination with JDeveloper. You can download it from OTN. It is based on JDeveloper 9.x and perhaps a little bit outdated, but it still explains the principles of source control and what it can do for you. JDeveloper 10.1.3 already offers much better integration, also with Subversion. I hope to be able to write a white paper about that too. Maybe it helps when you call my manager and tell him you want me to write it. Just say the word and I'll give you his phone number!
Anyway, the point I try to make here is this. The effort of installing a source control system like Subversion and maintain it, is only a fraction of the time people spend on things like manual merging. And then the risk of things going wrong. Come on project managers, you can do without that! It is hard to give you exact metrics, but based on experience I dare to say you already crossed the break-even point when two people worked together for a month. After that, you definitely keep money in your pocket. And the developers are happier too!
And once you have it, you suddenly realize it offers opportunities you were not aware of they existed before. Like going back to a previous version (for example the one that is in acceptance test) on instant, fix an issue there and almost with one click of the mouse go back to the current version and move on. Or find out who implemented that one great feature so you can give him or her the medal of honor of the programmer of the week!
(*) Actually, the saying 'having the memory of a gold fish' appears to do great injustice to this fellow creature. If it's true what they say at Goldfish pass memory test I would praise myself fortunate when I would have the memory of a gold fish.
Monday, August 28, 2006
The other day I had I discussion with a colleague about what many people call "non-functional" requirements (as opposed to functional requirements), being requirements regarding performance, security and so on. This colleague argued that “non-functional” exactly expressed what these requirements are.
“OK”, I said. “Suppose you want to buy a car. Can you agree with me that its top speed is a non-functional requirement? Especially since normally any car can easily drive over 120 km/hour, which is the speed limit in Holland anyway, right?” “I agree that the top speed is a non-functional requirement, yes”, he replied. “So what you are saying here is that you might not even take a look at the specifications, but just assume that it can drive fast enough. But at the same time you would not take the car when it would not meet functional requirements like having a CD player, enough space to stow your kids and a sun-roof?”, I asked. “Yes”, he said, “that’s what I’m saying”.
“Now what if you are a sailor that happens to live in Munich but who sails from Kiel. Mind you, the distance between these two cities is about 700 km (435 miles). But fortunately - with the exception of a few spots - there is no speed limit in Germany! You have a lovely wife and you want to spend as much time with her as possible. Would you then have a look at its top speed?”, I asked. “Ermmm…”
The point I had made here is that what some people consider to be non-functional requirements could very well be a functional one to somebody else. Like logging would be a non-functional requirement for the average user, while an EDP auditor might have a totally different opinion about that.
So please stop using the term “non-functional”, people! In real life people say non-functional to something that does not work. It is confusing and imprecise, where the development of information systems is a very precise job. Use “supplementary requirements” instead. The only disadvantage I can think of is that I still have problems saying "supplementary requirements" without twisting my tongue.
Thursday, August 24, 2006
Blogging as a phenomena has intrigued me ever since I'm aware of it's existence. Vain as I am, I can understand people blogging. But for a long time I failed to understand why people would bother to read them. Don't they have better things to do than read other people's whimsical thoughts, like a job or something? To tell you the truth, I still don't understand.
That is to say, with a few exceptions. There are a couple of blog's that I read once and a while. I won't give you names as I don't want to hurt the feelings of people that I will fail to mention. But most of them have one thing in common, which is that they are job related. In my case that means they have software development as main topic, especially where it concerns Oracle which is my current employer. And the bloggers themselves also have something in common, being that in their field they are somebody".
So, to give you a reason to read my blog during working hours and prevent you from getting fired on instant when your boss finds out about it, I promise I will keep this blog also job related. That is, when your job concerns software development, especially when the Oracle toolstack is involved in that. Somewhere.
And occasionaly I will share some whimsical thoughts with you. Hope you will forgive me.