08 July 2006

Quick Kill Project Management + GTD ratio

While there is a relative quietness in the Java Community as a whole since the advent of IoC etc. etc. Some new annotation-based web frameworks, new server-side scripting tools ala rails doesn't really draw too much attention. There isn't much breakthrough in Java EE for someone to move into it hastily. Developer's now realize that they always run into particular problems which has become a pattern in every project, a pattern usually starts with setting up the new framework for the development environment, testing it and hoping it works, if didn't then join the framework's forum and shout for help, in the case of commercial or proprietary tools it will take around 2-3 days and coming up with a wrong answer most of the time. This is where helluva sleepless nights starts.

There are plenty of tools and frameworks out there some are helpful and some are not. But nobody really talks about "getting things done" or GTD. I don't agree that this should only fall under the project management's responsibility. When we sometimes play a lead role in development team we focus too much on standardization from code writing to internal processes. But how much of these really helps in bringing up our GTD ratio? What standards should we keep and let go?

And then there's Quick-Kill Project Management a very interesting article from Dr. Dobb's. I think the "Quick-Kill" is just a catch because the way the process goes, except for the code review, is the same as the process we had on how I made my first Vernier Caliper out of our school's machine shop during my Secondary School/High School days. And that's a quick kill. And suddenly this quick-kill culture disappeared during college allegedly replaced by teachings of the "missionaries" from the West. And the word "buzzword" and "hype" started to find their way to our vocabularies. Of course, Quick-Kill is just one thing, yet again there's no mention on how mundane factors affect our GTD ratio. Some questions will help but shouldn't influence any policy-making decision.

1. How many hours a day your team spent answering all the emails? What email should be answered at the start of day and what should be answered at the end? Is it really necessary write email to the guy next to me?

2. How many hours a day your team surfs the Web for unrelated matters? You can't do a precise monitoring but a leader can motivate members to focus on the project.

3. How slow are the machines being used?

4. How the outsourced team are coping up?

How many hours a day should one focus on particular task to get it done? 3 hours? 4 hours? 8 hours? As one developer's experience grows, one core component of the project can be done in 4-6 hours giving a full focus on the assignment. Now if everyone can give full focus on the assignment, there are just too few reasons to stay late at night or work on weekends.

03 July 2006

Fine Tuning the Direction

After all the Java/J2EE talkees from different communities and different cultures and all the dizzying hypes and new web frameworks. I decided to focus on 2 key Java technologies as far product development is concerned.

1. Eclipse RCP/SWT
2. Jini/JavaSpaces

Some other things will become consequential like JDBC, I/O, XML etc. I hope JSR-212 or otherwise known as SAMS should adapt the real protocol-agnostic approach by using JavaSpaces instead of the traditional and vendor-hyped J2EE and should be called SAMS2. And I am keen to divert Patriot to be non-compliant in order to use the more adaptive JavaSpaces and will soon be called The Renegade just to speed things up.

Pitfalls that the uninitiated mind should be aware of will come out in the form of buzzwords such as "SOA", "Professional Services", "Out-of-the-box solutions", "Interoperability", "end-to-end e-business solutions" and other sweet-but-poisonous words that will appear to be simple. It's easier said than done so be really mindful. Unless you're really ready to die for this then ride the buzzword train. But when the World finds out that this is how you survive in a "hidden sector" of the IT ecosystem, you'll be skinned alive or be simply fried.

It's 2006, and it's very high time for Lean Development which really boils down to doing what's really important, documenting only what is required. Gantt charts are for sissies. 80% of my projects was delivered without it and 20% that used it was vaporized into thin air.