Friday, October 31, 2008

Sun Certified Specialist Netbeans IDE

Sun is testing the beta test (...) for the Sun Certified Specialist Netbeans IDE. There's a study group here and obviously you can find a lot of resources on the Docs & Support section of the official NetBeans site.

Download NetBeans!What do you mean "I don't know NetBeans"? what are you waiting for? Go get it!

First draft requirements: lessons learned

I recently talked to a friend of mine that had just terminated a preliminary collection of requirements for a couple of new customers; I found his insights very interesting for a bunch of reasons, and I'd like to report some lessons he learned and was so kind to share. Having seen the result of his efforts I'd like to add a couple of thoughts of my own.
  • Having just a person conducting the interviews and another one working on the resulting minutes is not a good idea (we're not talking about polishing them up), as it is very time consuming. Better to spread the work among two persons and interact frequently between sessions: even if it might seem more expensive, as it doubles the resources involved, it greatly reduces further analysis and review time and leads to better results (likewise pair programming). This practice also reduces bottlenecks.
  • A versioning system is very useful. Use it.
  • Time spent on "aesthetics", like formatting, logos and such, would be better spent at the pub. Ops, I mean concentrating on the core stuff. A good look should not be important to you. If you really need it (you normally do when you approach a new prospective customer) leave it for someone else when the process is (almost) terminated. Better yet, separate presentation from content.
  • Don't forget nonfunctional requirements. I am always astonished when I see that nobody cares (or remembers) about security, scalability, reliability, configurability, performance, and so on. I can understand a customer might not think of maintenability at first, but how is it possibile that nobody ever says things like "the system should support no less than 2000 concurrent users" or "the system should adapt to many different situations"?
  • Inspect and adapt. Rinse and repeat.
Note that the purpose of these interviews was the production of a first draft for a possible collaboration, not working software; nevertheless the same rules hold true also in production time.

Wednesday, October 29, 2008

Putting people first

Stuck in a traffic jam (two hours to commute instead of the usual 40 minutes, thank you very much) I read for the umpteenth time The New Methodology by Martin Fowler. This time the section that struck a chord is Putting People First, as it is closely related to something I've just witnessed (a friend of mine was involved).

The company he works for has repeatedly told him that they can easily live without him, despite the good job he's doing for them (yes, they acknowledged it); though this might be true (well, it surely is) there are some words of caution.

The first and most important is that this attitude can only lower morale and productivity, not only for the person involved but for the whole group, as it can lead to questions like "If that's the way they treat him, why should I be in a different situation?". Someone might think he's different, but the biggest problem when you have a problem is to admit you have a problem (sorry for the pun). And when do you want to know you have a problem? well, now, or at least as soon as possible. That's why good people realize it. To quote from the article,

The good people look for a better place to be, and you end up with what you desire: plug compatible programming units.

Unluckily, unlike plug compatible hardware units, plug compatible programming units are not a great tool.

Moreover, it won't be that easy in the beginning, and it has a cost: studies show how substituting someone can lead to burn up a lot of money, and to get the same productivity level can take up to one year and a half. You even start with a negative productivity, as in the beginning the new resource not only is a sheer cost, but also takes his peers time thus lowering their productivity as well (I will not do multitasking! I will not do multitasking! I will not do multitasking!).

The best way to work it out is an honest and open conversation (I know, I always say so... it's because I firmly believe it). A collaboration must be to everybody's advantage, and everyone involved should make sure that this is so; when it's not possible (anymore) it probably makes no sense carrying it on.

Tuesday, October 28, 2008

Italian Agile Day 2008

Italian Agile Day
I'd like to quote the official communication for the 5th Italian Agile Day:

Venerdi' 21 Novembre 2008 si terrà a Bologna il quinto Italian Agile Day. Si tratta di una conferenza gratuita di un giorno dedicata alle metodologie Agili per lo sviluppo e la gestione dei progetti software rivolta agli sviluppatori, project leaders, IT managers, tester, architetti e coach che hanno esperienze da condividere o che iniziano solo ora ad interessarsi a queste tematiche.

La giornata ha come obiettivo la conoscenza pratica, le esperienze sul campo e un attivo coinvolgimento di tutti i partecipanti. L'accesso è libero previa registrazione, i posti sono limitati.

L'evento, per la terza volta consecutiva, si auto-finanzierà.

Looking forward to meeting you there.

Scrum vs Lean?

Following this discussion I posted my thoughts on the subject. Even if I have just become a CSM, I have to agree about the importance of the certification itself; as our instructor Joseph Pelrine said, "I can only certify that we breathed the same air for a couple of days". This feeling seems to be shared by most hirers in the market. Nevertheless, I learned a lot in those two days, and I also had the opportunity to meet many skilled guys who share my very same interests.

That said, Scrum is about addressing the chaos you tipically get in a complex and fast changing environment, not about developing software: e.g. I always use it with my wife whenever we have to “refactor” our garden (ok, that’s not too complex an environment, but I’m sure you get the point). If you’re looking for practices to improve the quality of software, you’re looking in the wrong place. One word of caution: Scrum really fosters software quality improvement, but it does not provoke it. People improve software quality.

Scrum is not bad because you see many bad Scrum implementations; I’m sure you can find bad implementations of almost everything (OO is not bad because many programmers disguise their procedural code - which is not bad per se, but the mix of the two is often weird). I want to stress that a Scrum Master does not tell the team what to do, as he is not the leader; he is a servant to the team: sort of an istance of the “sacrifice one person” strategy by Cockburn, except maybe for the fact that in the latter you normally assign the sacrificed person a particular task.

I also agree with the fact that a team needs good leadership thus a good leader, even If I'm aware that many will not agree with that. I also think that the leader should emerge naturally in the team, and should not be superimposed. A team without a good leadership (I'm talking about an "internal" one) could easily end up out of action, especially an inexperienced one.

Monday, October 27, 2008

A new use for sudo

Gotta try it... will it only work with sandwiches?

The original comic can be found here.

Deep linking in YouTube videos

YouTube now allows deep linking in videos; all you have to do is to append the suffix #t=xmys to the URL of the video you're referring to, e.g. if you want to start after 2 minutes and 30 seconds you have to append the string #t=2m30s.

A job you love

Find a job you love and you will never work a day in your life.


Not all that glitters is gold

Many people keep asking for more responsibilities. Some of them know what that means, others just see the golden side of the coin. Un(?)luckily they will soon find "di che lacrime grondi e di che sangue", which means that "with great power comes great responsibility", and you'll have to expose yourself more than ever, to take hard decisions and to to pay through the nose for them.

Is that so bad? Not at all, but it has a cost you must be willing to pay, e.g. if a member of your team is not behaving as expected and is only a burden and you have the power to throw him off, well, you should do it.

Now... Are you prepared to fire someone whith which you've had lunch each and every day for the last years? I't true that after all they could find a job that better suits their need, and they almost always do, but it's not that easy to step past the line.

Friday, October 24, 2008

Scrum and XP from the Trenches

My friend Manuela suggested me "Scrum and XP from the Trenches", an introductory war story on Scrum written by Henrik Kniberg which I found very interesting.

I particularly liked the idea of a separate place for unplanned items on the whiteboard, as we normally pin them with the others, depending on the feature they address: even if the team knows why it's taking so long to get things done, the management always seems to not to. A huge cluster of unplanned items is a clear signal nobody can ignore :-)

This is another (working) example of the old bit "the simplest thing that could possibily work"... way to go whiteboard warriors!

Henrik and InfoQ provide a courtesy copy of the white paper here (you have to login first).

Monday, October 20, 2008

Scrum by the book

Talking about Scrum I got an objection which sounded more or less "you speak just like a Scrum book, don't you have more practical insights?".

That gave me something to think about. Scrum is really simple: the customer provides a "single choppable neck", called the product owner, who is responsible for the project and decides what he wants (on behalf of the company, of course), the team produces it, the scrum master makes sure everything goes smoothly. They periodically meet and review what has been done and plan for the next iteration. (If you aren't satisfied with this, and if you don't know Scrum you should, go get this book).

So... what's wrong when I say the customer should be involved? Or that communication should be the basis of every project? or that you have to let the team do their estimates? or that management has to trust the team without telling them exactly what to do (or better, without telling them how to fulfil the customer's needs)? I really don't get it.

Sometimes you sound like a book because if you talk your talk AND walk your walk AND hit your target... well you have no reasons to not to. You studied it, you tried it yourself, you got a piece of the action. That's it. You have to know and follow the rules before you can break them, or else you would miss the consequences. I normally pick XP as an example, where people think they can easily remove some practices: you can be quicker avoiding documentation, but this is compensated by having a customer on site (this is now called whole team). Forget that and you're doomed.

Maybe it's just hard to accept that someone else succeeded in something in which you failed (and if someone asks about the problems you'd get combining Scrum and XP this could be true). Or maybe it's just a provocation. As (our) actions speak louder than words I simply took it as a compliment - even if I'm sure it wasn't.

Performance problems?

Last week I was talking about the Spring framework with a team leader, and he was quite astonished when I told him we were not worried by performance problems using it. That sounds strange to me, as I was always told - and firmly believe - that you have a performance problem only when you experience it. Worrying about performance when you don't have problems could lead to overengineering, thus is not very good. Obviously you should try to load the system as soon as possibile, because you don't want to find out your architecture is completely wrong two days before you go into production, but that's a different story (and no, we did it and we don't have performance problems either).

As an aside, what kind of question is "tell me a method you'd use in Spring"? I normally care about my pojos, keeping third party's javadocs close at hand should I need them. I don't think I'm supposed to remember boilerplate syntax, and actually I don't - even because I'm not a one man band, but I work in a team where skilled people can do their job (guys you owe me one) leaving me free to do mine.

Thursday, October 16, 2008

JDK6 Update 10

The new JDK6 Update 10 is available here. More infos on the FAQ page (thanks to Fabrizio for the news).

Wednesday, October 15, 2008

Transition from Waterfall to Agile

Jatin Leuva asked what is required when an organization is transiting from waterfall to agile: this is an interesting, and very common, question.

First of all you should have good reasons for the transition: if waterfall works for you, you have no reasons to change it. Unluckily this is almost never the case.

So your process does not work, and you have to change it. I'd start with retrospectives: what went well, what you'd do differently, what did you learn, what still bothers you. This can give you a start.

Meanwhile, you have to work at higher levels, as agile methods require a shift of paradigm with respect to standard management techniques: managers have to trust people and must resist the impulse to tell them what to do, and this generates fear: fear of losing power, fear of being useless, fear of loss of visibility, and so on and so forth. Unless you dispel this fear, your organization will never get agile, as managers won't allow it.

That said, a very good way to start is to hire an agile expert to help your team (and your managers) get confident with the new process - I should say with the new attitude: your team must face a shift of paradigm too, as team members will not be told what to do anymore, but they shall commit to deliver useful software. They'll have to earn the trust that managers should have in them, as it won't come for free. It's not about skill, it's about committment.

Monday, October 13, 2008

...a very good service?

As a follow up, I just received an SMS that reminds me that on October the 3rd, 2008 I have a time slot reserved for fixing my glass. That would be nice if it weren't October the 13th...

Another case of machines vs humans: luckily I dealt with humans, who did a very good job despite of the systems (un)supporting them ;-)

Face-to-face communication vs Documentation

Recently I partecipated in a discussion on the topic above; here are my thoughts.

Documentation has a big flaw: it gets out of date. And it has a cost. And is subject to interpretation, anyway. Face to face communication is a very good option, provided that you have access to the right people when you need them, as what is unclear can always be further discussed. There are many techniques that help, as active listening and many others.

But the real trick that avoids information loss (at least it minimizes the risks) is the continuous feedback that the team gets by the customer, typical in agile methods. In Scrum, e.g., at the end of each sprint (normally 30 days) the team holds a demo in which a working product is shown to the product owner (a "power proxy" for the customer), and that's where eventual misunderstandings pop up.

Another technique is having the customer write his own acceptance tests, using frameworks like FitNesse. That's also a very good documentation at system level, because tests describe exactly how the customer expects the system to behave. At code level, i.e. for developers, automated tests are the best documentation you can get, as they exactly describe how different pieces of software behave.

What level of documentation can be expected? it depends, and it's not only about how agile your process is. If defects in software could cause loss of lives you'll probably have a higher process ceremony, which means more and more detailed documentation, if software defects could only cause loss of comfort or discretionary money it's a whole different story.

Wednesday, October 8, 2008

A new Certified Scrum Master

After a very intensive and interesting course held by Joseph Pelrine, whom I recommend to everybody interested in Scrum, I am now, lo and behold, a Certified Scrum Master (trumpets playing, cheering and applause). That's not so strange, as I have been very involved in scrum(s) for almost 15 years, as a forward player and as a scrum half... even if that might not count!

By the way, I was shocked by a revelation: the scrum half is not the scrum master, as the name might imply... he is the product owner!

Friday, October 3, 2008

A very good service

I have to pay my compliments to all the CarGlass staff for the very good service provided, from the first call to the contact center to the return of the fixed car.

Thursday, October 2, 2008

Why people resist change

One of our customers has started an ambitious project that I think will bring them great advantages; the only problem is that it will require a paradigm shift and will radically change the way many persons are used to work. Brooding over this project I found this interesting slideshow that reports the most common reasons for which people resist changes.

Good news? They have already identified a good strategy to manage the risk.

Wednesday, October 1, 2008

Things that should never happen

Being a father myself, my heart sinks whenever I read stories like this one. I hope that people involved have been read their riot act.