This post originated from an RSS feed registered with Java Buzz
by Jiri Lundak.
Original Post: Beware of ... Deceitful Productivity
Feed Title: Jiri on Java and Jini
Feed URL: http://www.kstaken.com
Feed Description: Jiri Lundak's thoughts on Java, Jini, Distributed Systems and Software Craftsmanship
In this second installment of the 'Beware of' series, I would like to begin with a true storyI am currently living at my current employer...
...once upon a time (about two weeks ago) there was an emergency meeting.
Our CEO had promised a current customer of ours to make a counter offer for a webshopsolution. We would have to demo the application within 4 working days.
So far, so good, if we had the module already, but we did not have it!
The idea was: Let us use the module, that our plattform partner company already hasand let us integrate it, with our catalog management solution.
Integration did mean two things:
Redesign the shop's user interface (HTML) to implement our look and feel.
And make appear our products in the shopping cart of the shop, byimplementing one Java Interface in our product object to return the price information for the shop
Not a big deal you would say, but the story goes on ...
Two days later we hear our CEO proclaim, that within five days, we would have todemo our catalog management system to a big company, and they wanted to seethe following features (I am only mentioning the ones we do not have at the moment):
eClass classification of products
BMECat import / export
integrated workflow management system
attribute inheritance across product-category hierarchies
integration with Quark Xpress
For all these features, we would have to spend to implement them properly about twomonths. At the same time, there were features, one of our existing customers neededurgently to be able to work with our existing catalog management system (being developed in record time from scratch in the last 6 months and thus missing all but thevery rudimentary stuff and being ridden with many bugs)
So there was another emergency meeting to decide, what could be implemented (orfaked) in such a short time.
The good news is: Hey, we did make it! As I am writing this our CEO is demoing thesystem to the customer. And we implemented every thing...
...kind of:
The HTML-GUI is really nice.
BMECat support was implemented, but is not really working (we will have to redoeverything from scratch)
eClass support was implemented, but the data model is not sound (its only anafterthought, so we will have to do it again)
the workflow module does work only for the most trivial hard-coded case (willhave to be redesigned and very much expanded)
inheritance of attributes across product hierarchies does work, but only on thelowest level and hard-coded (would make existing catalogs, completely useless)
Integration with XPress does only work for the two catalog pages we implementedfor the customer demo, and has to be implement yet to work generically
This would not really be a problem, if we would say: "Ok, this was only for the demo, letus dump it now and start over to get back to the real stuff!"
Instead our CEO said yesterday to me: "Are you not proud of yourself? You all developersdid a really great job! Our application is now on the right track. We have made a greatleap in productivity, haven't we? We have now made all the basic features implementedto compete in the enterprise market."
Is this real productivity?
The salesmanagers' view
From the standpoint of the manager and salesperson, this may well be. She is maybe ableto sell our product and acquire a new customer. The GUI looks fine, the basic functions arethere ... what do you want more?
But how does the developer's perspective look like?
If you are a developer, like some of the collegues I came across, then you are proud of yourself. You made a deadline! You worked 12 hour days, sure. But what a satisfaction, when your CEO claps you on the back, saying: "Well done, Johnny!". You go home, forget about the past two weeks and are ready for the next hackathon.
On the other hand, if you are developer, that tries to do more than the first thing thatworks and then forget about it. If you can not sleep well, if you feel the code rot underyour hands (even if it is packed up in a nice GUI). If you feel that productivity is morethan to quill out features at speed of light, then you will feel very uncomfortable in such asituation.
Analyzing your productivity
Signs of deceitful productivity are:
Your GUI looks fine and complete (... but there are lots of dummy entries)
You implement every day new features (but come never back to them laterto make them useful, complete and bug free)
Your architecture does not scale (performance, complexity) and you haveno time to do something about it
You plaster one feature over the other (there is no real integration, onlyon the GUI things seam integrated)
You develop the same feature more than once (because it is easier tore-implement it, than to change any entangled dependencies)
No team member has any overview of the system
There is no real deployment and team synchronisation process
You only react to market needs (instead of looking ahead and keepingalive a proper vision of where your software should go)
Signs of real productivity are:
Each piece of code or feature you deploy is tested and complete (thepiece itself may be small, but it is always complete)
You refactor mercylessly to adapt your architecture to real needs andto eliminate code rot as soon as possible
You take yourself time to rethink your architecture at regular intervals
Your developers can participate in developing any part of the system,with minimal time to get started (without compromising your design), asthere is continuous communication
You have a development and production process in place (even a minimalone) that everybody in your team follows
You develop and share a common vision on where your product shouldbe tomorrow, next month, next year and you do not compromise thatvision for any business opportunity, that crosses your way.
Sure, today's companies are under pressure from economic reality. There will be moments of faking functionality to get the customer or job acquired, but - and this is a big BUT - this should not be the prevalent notion about what real productivity is all about. Such moments should remain an exception, else -in the long run - they will ruin the prosperity of the company, as deceitfulproductivity will have a bad impact on the quality of your company's productand relationship with customers.
Do you make similar experiences in your developer career? Do other signs of deceitful productivity come to your mind? As always, let me know...
Previous Topic
