Tuesday, February 27, 2007

Dilemma driven development

Manager assigns a one engineer week task to his developer. The developer was some one who felt Java to be cool and happens to think that C is an assembly language. He hates (dreads) pointers but loves garbage collection.

Week 1 - Project Kicks off
Starts of coding very hard with lots of hard coded names and paths. On 4Th day he realises the need to for "constants". He stops coding and begins to "refactor" his code. After one week when asked about the status, he tells his manager about how Martin fowler invented the term "refactoring" (note I say invented the term not the concept) and transfers his half baked knowledge on "xtreme programming". The Manager picks up whatever jargon he can and offers the developer in return a one more week extension.

Week 2 - Developer's Dilemma
Dilemma - To use or not use a constant? To make his code "flexible", the engineer makes almost everything a constant. There are now around 400 constants. Does it look like I am exaggerating? Then come back after reading this article on enterprisocity.Next brain wave - "How about I move all the constants to properties file and load them from file"? By doing so I make the constants are configurable.

Week 3 - Introducing the Architect
The delay in deliverable is escalated and the Manager is convinced that the project is complex enough to introduce the "Architect". Architect without understanding the core problem instantaneously gets hooked on to.. Guess what? (yeah you guess it alright). He gives the developer books (only classics), Standards documentation on XML and says "XML is the way to go".

Week 4 - Architect's Dilemma
While the developer is busy XMLfying himself, architect is facing dilemma - DOM vs SAX parser. After some due diligence decides to go with a DOM parser. Architect and programmer are now divided on whether to use DTD or XSD for defining XML schema. Architect makes a final call "XSD" because in his previous projects they have used and it was better some how (clueless yet confident).

Week 4,5 - Back from Conference
Back from Meta StarDotStar conference, the architect is now not sure about his choice on DOM anymore. He learnt that DOM is memory consuming and not a good choice for large XML file parsing. The way XML based constants file is getting bloated up it would be a shame. It was time he surrendered to design pattern/framework whatever be the consequence. He became victim of Inversion of Control aka. Dependency Injection pattern.

Week 6,7,.. Project nearing completion (I mean closure)
There are three types of IOC containers - Constructor /Setter /Interface injection based. Which one to use? He opted for whatever the hot and happening Spring framework used. Now the XML parser is loaded on "runtime" using another XML configuration file. Developer is fighting class loader issues. Needless to say Manager was immensely happy to see his dedicated team work day and night solving "unknown" yet expected issues.

As I am writing, I hear that the project is being shelved and the team got promoted....


Anagha Mudigonda said...

Aha !
Why does this remind me of a certain hard working (week 1) engineer who ennnnnnhanced the scope of a certain project (MAS), jargon and all included, innovated and added week 3 to the project, created and played the 'architect' , caused the addition of hundreds of features and thousands of LOC :D and postponed the shelving of the project by a year !
And now he writes about it in a humorous way !!!!!!
Hah ! luckily for him, I fell in love with this engineer or else .................. :D

Vidya said...

I can map week by week the proceedings of MYPROJECT with your blog:)

Although introducing an "architect" is not so bad an idea ;-), Once "architect" got back from the CTO summit held at SFO he kinda got excited on preparing use case for MYPROJECT and soon realized that his passion on building super complex technology solutions.....had no takers actually:))
Ironically this architect is one of the best in breed currently around!

Then "architect" started advocating the loosely tightly coupled architecture such that the code bundle could accommodate itself in any given Telco operator space........ And the story goes on!!

Only the promotion is a pure blog item ....you seem to write like all stories have a happy ending;-). But is that reality????

Naren said...

Seems like your team is smart (lazy) enough not to fall in to your architect's trap. Here is
what my friend Keith says:

For some reason I was "cured" before I ever got to dependency injection. It's weird, but once I stopped using all those Enterprise Best Practices, my code got more robust (or failed appropriately and clearly much earlier), and I could put together a project as quickly as I said I would. Now to convince others.... ;)

Colm Smyth said...

This would have made a good WTF post!

Response: fire everyone on that project; the developer, architect and manager are clearly incompetent.

Solution: use Java Properties or (if really needed) Preferences.

Hand-crafted XML solutions (or say, Spring) are only needed for significantly more complex configuration needs. XML crafting should in general be avoided by using an XML-binding technology like JAXB.