Attached is an early draft of an article I’m writing for something at work. It’s about the things I noticed and had to reconcile as I learnt to play the role of a project manager on a large software project. Here it is – Against all oddities
Do let me know what you think!
I tried getting rails up and running on my (fairly) new iMac a few days back, and although I installed mysql gem currectly, the code was unable to connect to the mysql server. In fact, it threw an error –
mysql.c:2015: error: ulong undeclared
It befuddled me for a bit, because when the mysql gem is installed (gem list shows it), it compiles the native extensions – and that had succeeded. Or so I thought. Long story short – there appears to be a problem when trying to compile this gem on Intel Macs – and here’s the fix.
1. Go to gems directory – it will be somewhere under your ruby directory. Edit mysql.c, and add “#define ulong unsigned long” to it.
2. Then do ruby extconf.rb install mysql — –with-mysql-dir=yourmysqldirectory/
4. make install
This fixed things, and now, mysql can be used satisfactorily.
My previous post on estimation sparked off quite a conversation between a colleague and myself. It was a great conversation from which I captured a few points that I wanted to elaborate on.
First of all – what is the psychology behind story points? IMHO, the answer is Parkinson’s law – work expands to fill all available time. This is not a reflection on the ethics or abilities of a developer or anyone else engaged in a software project – but something that, as humans, we’re all susceptible to. Our minds tend to think in terms of reality – and of past experiences. This is why, when asked for an estimate in units of real time, people tend to factor in all kinds of eventualities. It is very difficult not to think in this manner. Keeping the actual timeline outside the scope of the estimation is very helpful – it helps the person doing the estimation think on a somewhat orthogonal dimension – that of complexity alone. This is why thinking in complexity units works so well. You can call them jelly-beans or NUTs (nebulous units of time) or WAG-points if you like.
A related point that I’d like to iterate, if it isn’t already obvious, is that this also helps keeping in check the tendency of folks to buffer estimates. Since the discussion is no longer in terms of real time, people aren’t so much concerned about being able to finish in the amount of time they’re assigning a story is worth or that they’d later have to stick to. Automatically, this helps in keeping buffers out. (Not that buffers are bad – but there should be a method to the buffer madness.)
A side-effect is that teams can quickly agree on complexity estimates. This is especially true when using a simple complexity scale – say Large, Medium, Small. I used this scale and as we gained domain knowledge and experience with the code-base, we added SmallerThanSmall and Tiny. These are worth 200, 100, 50, 20, 8 “points” respectively. I like to use a scale that (almost) doubles as it increases in complexity. Developers with differing levels of experience and domain knowledge can typically agree about where a particular story falls on this scale. This helps taking another subjective factor out of scope for the estimation activity as well – and helps in ensuring all developers can participate.
Finally, from a planning point of view – velocity and simple statistics take care of things. Despite the fact that developers estimate in story points, planning can be done in real units of time after translating the estimates using historical velocity numbers and applying them across the backlog. This part is almost trivial!
Boy – each day I use Notes, it seems to scale new heights of un-usability (is that a word?). This time, it was after I installed the Mac OS version of it on my new iMac. The fonts were tiny. Really, – so small, that I couldn’t even read anything properly… it was awful. Anyway – I gave it the benefit of the doubt – maybe my monitor resolution was too high, and that the default font size was set to something small. I figured I’d just change it.
So I went to the user preferences dialog. There it was, change font. But – while I could change the actual font being used, there was no way to change the size! I looked around, and really – there was nothing! Unbelievable. I googled around a bit, and there it was – some obscure software company had actually created a utility that allows you to change the settings for Notes on Mac OS. Including the font-size. Why a utility, you ask? And why only for the client on Mac? Well, obviously, because on Windows you can just edit the configuration file notes.ini. (Mac stores settings in binary format).
Yep. Usability at its best. Edit the configuration file. A couple of years ago, when I had to use Notes v5.5, I thought that the worst sin they’d committed was that whenever the application crashed (quite often), you couldn’t just restart it. It would lock a file or something and you’d have to *reboot* if you wanted to re-open notes. This continued till I found a utility called Zap Notes – which allowed you to restart Notes if it crashed without having to reboot. I’m sure it was a best seller.
What are we still using Notes for? ThoughtWorks is consciously attempting to move away from it – once our systems move out (which they are, slowly but surely – travel has moved, expenses and time-sheets have moved) we’ll say bye-bye to that horrendous piece of crap for good.
BTW, here’s the utility – it’s called NiniX
Update – I installed Lotus Notes R7 client for Mac OS X and it seems to be much nicer.