Don't Ask, Do Tell

There's a great piece up at The Pragmatic Programmer about some very basic, but very important OOP concepts. Read the article for a complete explanation, but here's a very short summary...

1. Don't ask an object for information about it's state and then make decisions based on that data. You shouldn't be making decisions about the state of an object and then changing that state yourself. This logic should be inside that particular object. Just tell it what you want done and then let it do that to itself.
2. Don't tightly couple objects together by passing data around from one to another. Once you've returned some data from an object, any semantic meaning associated with it is lost. Basic OOP states that data should be stored along with it's state/methods; i.e. in its own object. Related to point 1.
3. Don't use multiple methods to access/work upon a single invariant state variable. Multithreading will ensure that invariants can no longer be guaranteed invariable (unless you lock properly). Better to use something like a map() call to apply actions to data.

In other words, follow basic OOP fundamentals rigorously. Keep data and the methods/logic that act upon it together in one place. Don't scatter it all about.

S.P. Jain - Principles and Framework for Project Management

Five, 9 hour days of gruelling work later, I must admit that the course was totally worth it. The time literally flew by and I can say with a fair bit of confidence that my perspectives on the art and science of project management have shifted significantly.

I've learnt a lot and not just from the instructor (Prof. Ajay Parasrampuria). As he himself pointed out, with more than 200 man-years of experience in the room, there's not a whole lot he could have added. 'Course, he went right ahead and did just that! But more on that later...

There were around 20 participants from a wide range of backgrounds. We had people from USAID, GAIL and Emirates. Large corporations, small companies and one hopeful entrepreneur. People with more than 40 years of organisational management experience and those with very little.

And of course, me :-)

The most important and illuminating part of the entire 5 days was the sharing of past experiences by the participants. Some were more reserved than others and remained regrettably silent, but there was enough back and forth to keep everyone interested.

Now, I don't want to give the impression that we did all the work and Ajay just stood back and listened in :-). His knowledge of the PMBOK framework was outstanding, as was his ability to communicate with the rest of us. His ability to continually relate principles from the framework to his and others real life experiences was absolutely riveting.

Perhaps the most educational part of the course were the daily 'games' we participated in. Now I can't reveal the details since we were requested not to ruin the surprise for the next batch, but I hope I can say they were excellent learning experiences. For me, the moment of PMBOK epiphany came during one of them when I noticed just how easy managing the entire (rather complicated) project became once we abandoned our ad-hoc procedures and started to follow the process framework. Things started to slot into place almost immediately and it was shockingly easy to manage all that data and derive meaning from it.

The highlight of the course for me was the presentation on "Monitoring and Controlling IT Projects" by Mr. Tapan Bose, V.P. for Financial/Banking Projects at Satyam Computers. Lots of useful observations from the trenches and insights on what works and what doesn't. The main points I picked up was not to forget the human dimension (especially team building) and to treat the process as a part of the project, not as a template filling chore carried out under threat of audit.

Of course, the most depressing part of the entire exercise was the realisation by all concerned, of how little of what we'd learnt will actually be applied in real life. We might be all gung-ho about working according to the PMBOK framework in our next project, but without institutional support (what the PMBOK would call Enterprise Environmental Factors and Organisational Processes Assets :-), it's very difficult to be an agent of change. There has got to be buy in from top management, or it's all just an expensive waste of time.

Here's to hoping I can actually use what I've learnt!

TurboGears - It's all in your head

Turbogears is absolutely, positively, definitely, unquestionably completely amazing!

I started out with very rusty python (I haven't coded in it for more than a year and they've managed to sneak in new language features in the meantime) and only a cursory knowledge of SQLObject, CherryPy and Kid (the three main components of the stack). Around 4 hours later, I have an almost working Todo List web application and a grin on my face that could eat a banana sideways.

The only reason it took me 4 hours is because of the ramp-up time associated with learning any new technology. I had to stop every few minutes and read the docs, scratch my head a little and then continue. And the only reason the application is 'almost working' is because I've decided to extend the capabilities significantly and so I'll be re-writing it.

But pause to consider what I've just accomplished. I've got the canonical 'Hello World' of web applications up and running (well, almost) in less than half a working day and I'm so charged up about it, I'm already thinking of version 2. A whole SDLC compressed into half a working day! And the size of the code! The entire controllers.py file is smaller than the Hibernate XML mappings I'd have had to write to get something similar in Java.

But the most important part of the experience is the pythonic characteristic of TurboGears.

You can hold it all in your head.

With most Java frameworks and ORMs, you're running to the docs every few minutes, every time. With TurboGears, now that I've done it once, I really don't have to go back to the docs at all; at least for the bits I've worked with. That's a real source of satisfaction and a major cause behind the speed boost.

Time to complete my next app of the same size and complexity? I'm guessing 45 minutes :-)

Face Time and Free Stuff

I've blogged about the need to interact with people before here and here. Christopher Hawkins has written an excellent article that succinctly sums up what it's all about:

Face Time and Free Stuff