alegu

Kathy did it again...

2006-04-20T14:37:00.000+02:00

I always tried to avoid this (just blogging a reference to some other blog) but sometimes stuff is just perfect as it is and everything I could possibly add would just be waste. So just click on this link http://headrush.typepad.com/creating_passionate_users/2006/04/angrynegative_p.html and read Kathys blog entry. Brilliant and enlightening as always!

Ciao Alex

Eric Evans Interview

2006-04-13T08:27:00.000+02:00

Yesterday evening I had time to listen to the Eric Evans interview Markus did for our podcast (http://www.se-radio.net/) and I think it is great (yes I know, I am far behind).

Eric Evans is the author of the IMHO very important book Domain Driven Design. In the interview Eric talks about his view on many topics like domain specific languages, MDA and of course domain driven design. I know this sounds like a shameless plug, but as I was not the one who interviewed Eric I think I'm actually more a listener than a producer here. But judge yourself, I only can recommend the interview...

Ciao Alex

I remember now...

2006-04-01T13:59:00.000+02:00

For those who know and care: Revolution is calling again!

Ciao Alex

P.S.: Nevermind if you don't know what the heck I'm writing about...

Mastery

2006-03-30T07:30:00.000+02:00

I have to share a little excerpt from the brilliant book "Mastery" by George Leonard:

"What is Mastery?

It resists definition yet can be instantly recognized. It comes in many varieties, yet follows unchanging laws. It brings rich rewards, yet is not really a goal or destination but rather a process, a journey. We call this journey mastery..."

and:

"The modern world, in fact, can be viewed as a prodigious conspiracy against mastery."

Oh, how right he is! I haven't completed his book yet, but already added it to my must have read list of books. A very thought provoking artwork!

Ciao Alex

My job didn't go to india (at least not till today)

2006-03-30T07:28:00.000+02:00

This time I can keep the blog entry pretty short: get out to your favourite book store or log in to your beloved online book store and do yourself the favour and buy the book “My job went to India (and all I got was this lousy book)” written by Chad Fowler. It is great! Mr Fowler has written a pearl of a book, that is a perfect companion in these days where the markets (and therefore also the job market) are more and more volatile. The book describes how to improve your career prospects through professionally managing your career. It for sure will help you no matter whether “India” is a threat to you or not. The world is changing and we will have to be prepared.

Dynamic by nature

2006-03-23T10:16:00.000+01:00

A few days ago I had a discussion with a friend about Ruby and its very dynamic nature (which I like a lot). He argued that with Reflection, ByteCode generation etc. you can do all the stuff Ruby does in Rails in Java too. Therefore he thinks it is just a matter of time until something equally cool as Rails will exist in the Java world. Well, I don’t think so…

Here we go. This little Ruby code snippet that doesn’t do anything much helpful but demonstrate a few things, that at least I don’t know how to emulate in Java (or C#, not to mention C++):


class Module
 def method_added (id)
  print "."
 end
end

class C
 print "1"
end

c=nil
i_am_a_string="c=C.new()"
eval i_am_a_string

class C
 def x
  print "2"
 end
end
c.x

class C
 def method_missing(i)
  print "3"
        end
end
c.a_not_existing_method

The output of this little Ruby script is of course “.1.2.3”. I don’t want to explain everything in there, but there is a callback method registered to get informed of any adding of methods to a class at runtime(!) which I do a little latter. It executes a String within the context of the main program and finally it deals with a call to an object that doesn’t have the method the caller thinks it has. Not that I say everything in there is necessary to do all the time (or should be), but the power is there. Therefore if you have to create a framework like Rails in Java, you might get one or the other problem ;-)

Ciao Alex

P.S.: Yes, I am aware that there are some "frameworks" out there that try to mimic
Ruby on Rails, but I very much doubt they can give the same "feel" Rails does.

P.P.S.: How can you post code snippets in Blogger with the correct indents? Any ideas?

Winning

2006-03-16T08:51:00.000+01:00

If you read the title of this entry and you read my last blog entry you could get the impression that this one will still deal with the book “Winning” written by Jack Welch. In a way it does, but just the other way around. I will write about what I missed in the book. Actually I can’t understand how the content of this article could be missed as it is maybe the most important factor: This blog entry will tell you how to become a winner. Not more not less.

Over the last 15 years I had the great luck being able to work for a lot of very different companies. Small ones, huge ones, software companies, banks, consulting companies and so on. This might actually be my hugest personal asset. And in retrospective there were winning companies and losing companies. Actually the winning and losing factor in some of them was pretty extreme. Some of the companies don’t exist anymore; others prosper and rush from success to success. If I look back, with all the now existing time and mental distance in between what differentiated the winners from the losers?

First of all, it was not that the people in the winning companies were that much better or more intelligent or had an by far better education. Actually they were better in average but the difference is not that huge. It was not that they had a brilliant product idea no one other ever had or couldn’t copy. It was not a function of size or money from inside or outside. It was not some brilliant management method, process or methodology. And I could make the list a lot longer than it is. The companies were very different in every imaginable aspect you could think of. But the winners had one thing in common: they had a culture of winning! If I look back they just won, won and won. If I look back at the losers, quite the opposite: they lost, lost and again lost.

The funny thing is, this is not true. The winning companies also had their share of catastrophes. They had failed projects. And one winning company I worked for even didn’t recover from one disaster and died. But in a winning company you see successes. The problems are seen to, but they can be solved and will be solved. It is how you percept your work. In losing companies you just see the problems. They have their successes too, but no one actually cares. And the crazy thing is, both views work self amplifying. If you don’t believe by heart you are a winner, you will never win! If you only talk about problems you will always fail. It is that simple!

Ok, I literally hear your disagreement, sentiment and disbelieve. This sounds like stupid “Chaka” management motivation bla-bla. And maybe the principle that all these motivation trainers use is the same, I don’t know. But actually I don’t care as I know the principle is correct and works. The difficult thing is, that this is not a thing that works because you hear about it. You have to believe it, breath it, be it. It is so f**ing simple and stupid, that it is almost unbelievable. It is this classic “the glass is half full or half empty” thing.

In winning companies if there is a problem, you try to fix it. If someone else has a problem you try to help him. In losing companies you have various options to react: bad mouthing, ignoring, saying “I knew it from the beginning”… But helping out is the least probable. In winning companies if you see you are late you do everything you can to fix it. In losing you just don’t care and ignore it, you try to hide the fact or you search for someone else who is guilty for. In losing companies you always talk about “them” as they made some mistakes, in winning companies you talk about “our success”. I swear you, it is so much more fun to work in a winning company, it is just unbelievable.

And no, this is not about “motivation” in the sense of “how hard you work”. It is about how you see your world and therefore how you motivate others (or the opposite of course). You might work day and night and therefore be highly motivated but destroy someone else motivation for weeks with just one sentence. But if you are out to win, you will fight for your success, and not just play not to lose. Winning teams are always in “fight mode”.

I am not sure what impression you have now if you read everything up to this point. If you right now work in a winning company, I guess you nod in agreement. If you are in a losing company you might disagree or not. But if you are in a losing company think about how much more fun your life would be if you would become a winner. What if I am right? What could you possibly lose if you would try?

How about a simple test? Take a piece of paper. Now write the 10 last catastrophes, killer problems or troubles your company has on the paper.

Did you do it? Please try before reading on….

…So, was it easy? How did you feel while writing? Now turn the paper and write the 10 most recent successes of your company or your team on the paper. Where you able to find 10? Not? Why not? Where did you emotionally react stronger? On the problem page or the success page? Maybe you now should read this blog entry again.

Lets sum it up. Winning is foremost a matter of attitude (of course it is not the only factor but the predominant). There is just one person in the world that can make you a winner. YOU. Nobody else but you. If you get into winner mode and your colleagues will, you and your company will win! If you don’t believe me try it. You will see, you will be able to do things no one ever would have thought you ever could.

Alex

Defined vs empiric processes

2006-03-09T09:27:00.000+01:00

Tobias wrote a few thoughts about defined vs empiric processes. Pretty thought provoking. Is the only difference between these two types the level of granularity we look a the process? What does this mean for process design? Wow, I guess I have a lot to think about, over the weekend...

Ciao Alex

Are you great?

2006-03-08T09:18:00.000+01:00

Today I finished „Winning“ by Jack Welch. I have to admit, I had some prejudice before reading (actually listening, as I have the audio book) because I think from all that I heard before Jack Welch has a fundamentally different value system than I have. And actually it shines through in some moments. Nevertheless I have to say, that I really liked the book a lot and that there are very few things to disagree. Maybe that’s a criterion why this book is not just good, but great. It helps you independently of your leadership style even independently of your value system. One chapter I really like a lot and I want to write about now is the chapter “Hiring”. Mr Welch says, you can only win if you have the right team. I couldn’t agree more!

Yes there is a lot of lip service on this, especially in the software industry. If I remember correctly, in every single interview I did in my life all the companies had an “over the edge, great team of super proffesionals”. I am really lucky to just pick the right companies and I feel very sorry for all the poor companies where only the below average people work. Needless to say, that the reality did not always match exactly the situation told/sold in the interviews.

But back to Mr. Welch: if the team is the most important success factor, a leader should spend a lot of attention to hiring. And again I have to completely agree. If a leader can only do one thing right, he should focus on hiring. So Mr Welch offers a set of characteristics you should pay attention when doing interviews where every employee should score very well (in most if not all points):

Integrity: The first is integrity, which is pretty obvious so I will not write too much about it. But you should obviously never have somebody in your team you do not trust.

Intelligence: Again he is right. It is not so much about knowledge anymore. In times where half of the things you know are worthless after 3-5 years why bother too much for knowledge. More important is the ability learn faster than the speed of light! So don’t confuse knowledge with intelligence.

Maturity: Wow, that is not too often used as criteria I would guess. But he is so right again. It is so exhausting to work with people that are not mature. And this is not a function of age! I know guys who are not even 20 years old and are more mature than others I know who already left their 40s behind. So watch out for this one!

Positive Energy: There are these people waking up with a smile on their face just longing for the work day to deal with the toughest problems. They seem to have infinite power. If you are able to get one on your team, don’t wait a second…

Energize Others: This one is different from the point before. It is not about having energy it is about freeing the energy of others. This is an ability that is so important in tough times. Do you have enough of this in your team?

Edge: This one is hard to explain. There are people who always make the right decisions and more important, know when to make the decision. They don’t need all the facts just enough to make no mistake. As I said hard to explain, but I hope you get the point.

Execution: Execution is about “just doing it”. Simple to describe, hard to do and unfortunately not too wide spread.

Passion: This is the last one. There are people who have passion for their job. And this is what you need. If you don’t feel passion for your job, your doing something wrong (which most people I know do). But that might be another blog entry.

So why do I write this, when most people never have to decide whether to hire someone or not. Simply because these criteria are not only helpful for hiring. Again, most of the people I know would say they are great, outstanding or at least above average. And again, if Gauss is right (and he seems to be), where are all the others? So if you think you are a great employee, a great developer, how do you score in the fields above? Are you mature? Do you energize others (and would they answer the question the same way you did)? Are you really passionate about your job (so when have you read your last book on something about your job)? If you are unsure about the answers why don’t you ask a fellow about his view of you? Being a good (not to say worthy) professional employee is harder than it might look…

Ciao Alex

As soon as possible but not too soon

2006-03-01T09:16:00.000+01:00

This is the third part of my epic on feedback. In the first part we looked into why feedback is so important. The second part discussed why feedback should be candid but nice. This time I will write a bit about timing. Why is timing so important? Because we still have some problems inherited from the times we where welcome dinner for animals that mostly died out today:

Do you remember the Greenpeace advertisements on the greenhouse effect in the early nineties (or where it the late eighties?)? They showed us a frog in a glass bowl. First they spilled some boiling water into the bowl and the frog of course immediately jumped out of the bowl. - Cut – Then again: the same start position, a frog in a bowl of water. Now they put a small gas burner under the bowl. No reaction from the frog. – Cut – Then they said that if you gradually heat up the water, the frog will actually get boiled (and the parallels to humanity and the greenhouse effect are obvious). Well, I don’t know if the frog thing is actually a fact or myst, but timing is VERY important when it comes to feedback.

Studies show that the farther away the feedback you get is from the actual action the less probable it is people realize the connection between the events and therefore will learn from it. Another example (from the great book “The fifth discipline” which in my opinion everybody should have to read) that you might have run into already: You might on some of your holiday trips have had the following problem: You take a shower and the water is much to cold. So you turn up the temperature a bit. Well it still is cold. Then again, you turn the temperature a bit up. Same result, it is too cold. Next action, you turn the temperature up again, this time a bit more. What happens: the water after a few seconds comes out boiling. So you take the counteraction (jump out of the shower and turn down the temperature a bit, nothing happens, you turn it down a bit further and ….).

So what happened? There was just a time lag between your action (turning up the temperature) and the reaction/feedback (water gets warmer). You just didn’t know. Another “real” example from the fifth discipline book: headache. Sometimes when people have bad headache they take some aspirin. Well of course aspirin takes some time to help. But often people get frustrated that the headache doesn’t get away fast enough, so they take another aspirin, which of course is the wrong reaction. The examples are numerous…

Why is fast feedback so important for us? Because we are biologically optimized on short term threats. If some wild animal tries to take you as little snack it is not a very good thing to worry about your next Christmas presents. So in the wild, we always prioritize short term threats over long term effects. That’s why we just don’t see connections if the time between action and reaction is to long. The funny thing, it is even difficult if we get told, that there is a connection (remember the example greenhouse effect).

So try to give your feedback as soon as possible. But then again not too early. Remember my last posting. If your feedback hurts it will not work. So, if you are in an emotionally heated debate it is not a very good time to give feedback. If you want to give the feedback in front of some fellow workers and therefore embarrass the feedback receiver it is not a good time to give feedback. Then it is much better to wait. But not too long. Always remember the goal of your feedback. You want to receiver to accept and react on your feedback. So try to optimize your part of the game…

That ends my three part feedback blog series. Of course there is some much more on the topic I can’t write here. Giving and getting feedback is tough and a thing we can optimize for our whole live I guess. And in my opinion it is important enough to do so!

Ciao Alex

Candid but effective

2006-02-24T10:37:00.000+01:00

In my “Getting better” posting I wrote about why feedback is the most important thing since sliced bread. Well actually why it is so important, mankind would never have gotten sliced bread without feedback loops. So the question of course is how does effective feedback look like? This question is so important that tons of books just deal with this problem. It is pretty obvious that this blog entry can’t and doesn’t want to answer the question completely. But I will try to give you in this and my next blog entry a few things I often run into and hope my findings might help you.

For being effective feedback of course has to be precise, correct, understandable and candid. If it isn’t, it will not help. It is as easy as that. If the person receiving feedback is not able to understand the feedback, how can he act on it right?

So that was easy at least in theory; being precise and understandable isn’t easy in real live actually but let us ignore that for a while. That’s what you learn in any feedback training. Be candid!

But a lot of people are not only candid but actually hurt the feedback receiver. Being honest doesn’t mean you have to be rude! For more on this just read Kathy Sierras brilliant blog entry “Are nice and honest mutual exclusive”. Of course they are not! Actually most of the time people who say they are just honest, they are just to lazy or ignorant to spend the effort of saying the same thing in a way the other person will not get hurt. You can say anything in a non offending way (one of the points is not to criticize the person but the action). Sometimes you will do it wrong because it isn’t easy, but that’s ok. But it is not ok, not to try.

Why do I mention this: because it is one of the often made faults I see when somebody gives feedback not trying to understand how your feedback will feel for the receiver. Remember WHY you give feedback! You want somebody or something to improve. But to get someone to learn (which is the first step, to improve a situation), he has to be open minded to your feedback. And he will not be if he is upset! So calling someone a dork will not open his mind and want him to listen and react on your feedback.

There are studies, that people getting angry or upset will be so for many many hours and that your body actually doesn’t work in a relaxed mode in this period of time (take a look at Daniel Golemans very recommendable “Primal Leadership” if your are interested in the scientific background). So upsetting somebody will make learning impossible and your feedback worthless (and even worse, the person will not be able to work effective for the rest of the day and even worse might change his perception of you and therefore your whole working relationship is at risk). So it is against your own goals.

So always watch out for the thin line your candid feedback should never cross. Always try not to hurt the person you give the feedback. Always first build up an open and non threatening atmosphere. Never give difficult feedback in front of others. Never expose the person receiving the feedback. So be candid but nice! And yes I know this is difficult, very difficult in fact. Good feedback is an art (and one I surely have not understood completely yet, but I always try to get better on it). And I surely think this is one of the key competencies everbody should master.

Ciao Alex

Deep professionalism

2006-02-21T16:12:00.000+01:00

On Saturday I had the great pleasure to hear Deep Purple (and Alice Cooper) live in Munich. And it was a great concert. The deep level of professionalism is so impressive (and that has nothing to do with likeing their music or not). With every note they play you feel how save they feel playing music. If you listen to them and watch them playing you feel their 40+ years of experience playing their instruments. And that is great!

I really miss this so much in the software industry. As I often speak on conferences I had the luck to meet some of the greatest thinkers in our industry, but we all have to learn a lot from these musicians. They don't have to impress you anymore, they just play. Transformed to our industry: they don't have to sell you their latest favourite hype topic. They know many ways of solving your problem, not just one. They just solve your problem. That's a long way we have to go...

(And the speed of change in our industry doesn't help, but it is not always only their fault, you know?)

Ciao Alex

Getting better

2006-02-15T08:55:00.000+01:00

“Getting better” is a key capability in life. And it is for any aspect of life. Of course you need to get better with the things you have to do at work. If you are constantly getting better either you inevitably raise your salary on the long term or at least you stay as long in your job as possible in bad times.

But getting better is not only a business thing. Getting better with all this fuzzy people stuff is so much more important than e.g. knowing how to use Java generics or hacking the Linux kernel. It helps you with your friends, with your spouse, of course in your job and even if you argue the price of your new car with your car dealer. So learning how to “get better” is central.

That’s why I decided to blog a bit about it. And this is actually the first of three postings about feedback. But wait a minute: haven’t you said getting better is the point you wanted to write about and not feedback? Yes, but this still makes sense (well at least I think it does ;-). Just let me explain:

Getting better with something is a synonym for learning. And while there is something like “physically learning” something most of the “getting better” situations in modern life do actually mean mental learning.

So what does it need to learn something? Actually a lot: you have to want to learn it (at least this helps), you need the right mood and a lot of other things, but one essential thing is: you need feedback loops! Feedback is one of the most important things for learning. Maybe the only essential. But one thing is sure, you can’t learn without feedback!

Nonsense you might think, I learned a lot of things without any feedback loops. Really, did you? Think about it, how do you know if what you do is good or bad without feedback loops? Imagine you want to learn playing the piano. And now imagine the only piano you can use is absolutely silent. It doesn’t produce the slightest tone. How could you ever know what you play, how it sounds and how to improve your playing? So here we have one of the huge misconceptions about learning: practicing doesn’t make you better by default. It doesn’t matter how much you practice without feedback loops you just waste your time!

So let’s bring that back to real life: a lot of people think they are good at their job because they’ve done it for decades. This fact alone doesn’t mean anything! Do you think you are good at your job, just because you did it for a long time? Are you the best hacker on earth just because you started to program 15 years ago? Think again! Do you have a mentor giving you feedback? Have you asked someone to give you feedback on your work products lately? Why not?

Now let’s switch positions from feedback receiver to the person giving feedback: Somebody annoys you, because he is so stupid. He just doesn’t get it. Or he constantly annoys you with his unfriendly and offending way to treat people or especially you? Did you give him feedback on this, so that he had the possibility to actually learn and improve on the points that annoy you? If not how could he find out what’s wrong? And no: the answer “but it is so obvious; he should have gotten it by himself” is plain wrong. Just that it’s obvious to you doesn’t mean anything. Even if it obvious to everybody else, it doesn’t have to be for him.

And also: giving feedback once doesn’t help necessarily. Learning is tough and changing habits is even tougher. So it takes time, it takes practice it takes repetition. Repeat your feedback if necessary. If you give feedback the right way, either it will work someday or you will get the answer why the other person does do it another way than you might think is best (this time it’s feedback to you).

So let’s sum it up (the post is pretty long anyway): learning is essential. Feedback is essential to learning. Feedback loops come in simple forms like “I see the result of my action” and as “feedback from other persons” which is necessary every time the simple form is not sufficient. So give feedback and try to get feedback! A lot of feedback! But how does effective feedback look like? Well that is the content of my following two postings. So stay tuned…

Alex

P.S.: As always of course: your feedback is welcome ;-)

My first podcast

2006-02-02T07:42:00.000+01:00

Last Sunday I recorded my first podcast together with Markus Voelter (take a look at http://se-radio.net, it will be released there soon). I have to say this was really tough, because it is multitasking in a extreme way. You actually have to do three things at a time: first you try to read and follow your script (we actually write outlines of the conversation to get the content more fluid and complete and to make front up group reviews possible). Second you have to listen to your interview partner, because he actually throws in additional questions if it makes sense. And third I try to speak English. Well actually if you listen to my first webcast you will notice that not too many cpu cycles where left to speak English, so sorry for the very very bad English. I know, some parts almost hurt. I hope it will get better with the next recordings. Nevertheless, recording the webcast really was a lot of fun and therefore I promise there will be more of them. Soif you are interested in additional topics or you have other comments, just let me/us know. We will do our very best to deliver content that is interesting for you. So we depend on your feedback to get it right...

By the way: a lot of people asked me how we actually did the recordings (knowing we all live in different cities). Well its relatively simple. We use Skype to record our talks and just edit them a little bit afterwards. But not very much as it massively disturbs the flow of the conversation for the listener. So, not too much high tech here. It is actually all very simple...

Breaking all the rules

2006-01-30T12:33:00.000+01:00

Open Source development will never work! Well, at least if you believe in common wisdom. Let’s take a look at a few examples:

- No monetary rewards: People do OS for fun, for recognition and other motivation factors but seldom for money. That shows very clearly that we human beings of course work for money, because we need food, a warm place to sleep and so on. But there is so much more! I still think this “fun and recognition factors” are a much stronger driving force than money. So all this companies that try to compensate lacking fun with money (or don’t compensate at all), watch out what you are doing and don’t be astound if some competitor will be a lot faster or better than you…
(Update: please don't missinterpret this as money is not an important motivation factor. It really is. It is just not the only one!)

- No fixed long term assignments. In OpenSource people fluctuation is quiet normal and not a huge problem. Because it is a fact, everybody deals with it and it is actually manageable. I think this is one of the reasons in OS projects code quality is so important. It makes change so much easier. So what can we learn from this? Projects can deal with fluctuation easily if they are done right. But you have to deal with the fact front up: you need a lot more conversation, better code quality and so on… For the team members this means: no one is irreplaceable. But this also makes change possible. If done right, no one has to stick with the same projects for years if not wanted..

- No direct interaction/communication: Well I and a lot of other people think communication is one of the most important success factors in software development projects. As direct face to face communication is the most effective form of communication I always try to facilitate face to face communication. In OS projects most people never meet. Almost all communication is done through instant messaging, news groups and email. And it works! Actually having a lot of communication done in newsgroups is a great help, because this gives a great knowledge repository for anyone (see the “no fix assignment” point). So what does this mean for conventional commercial projects? To be honest, I don’t have a clue. Maybe we should do some more discussion in local newsgroups and wikis? Maybe not? What do you think on this one?

- No BDUF: In OpenSource you almost never have detailed requirement specs, big front up design session, a lot of architectural documentation or concepts, nothing like that. And it works like a charm. So this clearly proves the point to me, how soft software actually is, and that the XP guys are right. You can live without BDUF! But you have to keep your software flexible to make this possible. But it is possible. Maybe it is even the best way to do software.

- Huge teams: A funny point about OS projects is there team structure. You often have really huge teams and a small core of developers doing most of the work. This actually resembles pretty much the structure of huge commercial projects (but there all team members invest the same amount of work time). Maybe software development has to be like this. Maybe this is a copy of the Gauss curve of skill sets?

- No developer wants to do bug fixing. If this would be true how could OS projects survive (as everything there is voluntarily). Who would fix the bugs? Obviously this is not true. Actually in OS this is a perfect chance to get on speed as a new developer. The other point is, developers that are proud on what they program can’t stand with a buggy product. So that is also a matter of identification. If developers don’t want to do bug fixing, maybe you have a completely different problem. Maybe you didn’t allow them to do it right from the beginning. Or maybe your product is so bad right now, that no one sees the point in fixing small bugs while not fixing the larger problems your code has?

- The best developer gets the leader: That is not so much the case in normal business or at least it shouldn’t if you would do what the experts recommend. Managing projects and people has a lot less to do with programming than with dealing with people. So usually you promote people with strong leadership and people skills into management. You don’t make the best violinist the conductor of the orchestra. Well in OpenSource projects you often do. But even in OS projects usually the people skill will get more important the huger the project becomes, so there might be not a big difference, nevertheless it’s interesting to watch. And in OS projects you will never find a project manager with no technical expertise. How about commercial projects for this one?

Well I guess before I bore you even more, I better stop here ;-) So obviously OS projects are different. And they are highly successful. So some of the rules how to do software development right, that we all take for granted are not as universal as we sometimes might believe. So let’s watch out and learn from Open Source…

Planning in agile development projects

2006-01-21T15:48:00.000+01:00

Planning is so different in agile development compared to the classic development methods: Most people who never did agile development and just heard the buzz about XP think that there is no planning in agile development. They think agile development just is "sit down and hack like crazy".

On the contrary some developers I worked with on "agile projects" complain, why do we have to do all this f**in planning stuff all the time. I don't want to estimate my stories/tasks/... I want to code. Hey that's why I am a programmer and not a project manager. Just let the architects and the project managers do the planning.

How comes the views are so different? Well easy, planning is very different in agile development. In classic development processes you usually do most/all planning front up. To be able doing this, you of course need all requirmenets, all architectural desicions and a lot more front up. We agile advocates say, this is not very realistic to get done well: no one can make all important desicions that far front up. And the more complex the problem the less it is possible working this style. So we say, we decide the "last responsible moment". That does not mean we decide never or after some point of no return passed but as late as possible. Well thats actually not as easy as it sounds. So agile methods did a lot to make this work. One thing is a different approach to planning. In agile methods you have to plan much more often (compared to just front up). You plan every iteration, you plan weekly and even daily makes sense.

So going back to the introductionary critics: No, agile methods DO plan. Actually planning will be done all the time. The second objective is more complex: no I don't think there is more planning in agile development (but I don't have numbers, so that's just a gut feeling), but I it is done more often (so timewise spread about the whole project lifecycle). But think about how projects start doing them in the traditional way. There are usually weeks and often months of front up planning. That's a lot of time, even compared to weekly project meetings (you need eitherway)

And in agile projects planning is not just a job for project managers and architects. And I considers this a huge feature. I think it is a huge mistake and has very unfortunate consequences letting someone who doesn't actually do the job estimate the job (that might give another blog entry someday).

So yes, it might feel more "planning", especially for developers, but I don't think it is.

Show me your software development process...

2006-01-04T09:22:00.000+01:00

In germany we have a saying "show me your friends and I tell you who you are". Actually there are a lot of variations of this like "tell me what you eat and I ...". I will add my own here: Show me your software development process and I tell you who you are. I think it is quite amusing and helpfull to review a software development process from this point of view:

Eg. take a look at RUP: RUP is an artefact driven process. It tells you which artefacts you have to create, when and which role has to create the artefact. It doesn't tell you HOW to do it. So this sounds a lot like a management view to me. A manager has to tell you what you have to do but shouldn't tell you how to do it (delegation works best when you as a manager let the expert decide how to do his job).
Or another hint: take your favourit RUP book from your bookshelf and take the number of pages of the book. Then go to the table of contents and count the number of pages that deal with the pure coding aspect of a project. Got the point? I know coding is not the only part of a project, there are so many others (may be even more important aspects), but after all coding IS one of the main activities...

Now go to the other eXtreme and take a look at eXtreme programming. XP is so development centered hardly anyone but a developer can create a process like this. XP almost tells a developer almost on a minute exact basis when to do what (eg. when to switch pairs or when to see the green bar). On the other hand it does not deal to much eg. how the manuals for a software will be created, how to do a consitent and good looking UI design etc.. Not that it is impossible to do it, it's just "not documented".

So why do I think this is not only funny but important: if you have to implement a software development process, watch out for "missing parts or views". Of course no methodology will work out of the box because every project is different so you have to customize your process anyway. But this point of view might give you some important hints where you have customize first, or which group in your team will most probably like or dislike the new process.

Sometimes if you want to introduce a more exotic process this can give you a hint if the process has ever left the ivory tower and was used in real projects. Acutally only a view processes (in their documented form) will survive this check. Eg. feature driven development is a rather "complete and balanced" one.

Does this mean incomplete processes are bad. For sure not! Especially the very unbalanced XP is one of the greatest steps forward in software development methodolgies in the last years and has brought us loads of great stuff. But it has it's sweet spot (and by the way, one great point about XP is that it's sweet spot is documented and it is not meant to be one size fits all, like most methodolgies in the 80ties). So use this just as a little tool when you have to work with software development methodologies...

Alex