The “Lazy” Ones

TestEarly.com is talking about why to Fire your best people…reward the lazy ones.

I did an analysis of my team and the people I work with. Interesting how many I could identify of both kinds. Try it with your environment!

JBlogEditor and JHelpBuilder

It has been a long while (years) since I made a release of JBlogEditor and JHelpBuilder. In my free time, I have always added code here and there to both project, but no significant new features.

I now realize that it is a futile attempt on my part to spend significant time on both these projects. I have uploaded the latest release and source code of both the projects to their respective web pages. I would still be answering questions on both the products, but will not be doing any new development.

With this, my respect for those developers who contribute to open source/free projects in their free time has increased many folds. I now realize how tough (and a big sacrifice) it is do so.

Code Quality

So how do we define “code quality”.
Here’s how Wikipedia defines Source code quality. The key points: Readability, Ease of maintenance, testing, debugging, fixing, modification and portability, Low complexity, Low resource consumption, and Number of compilation or lint warnings.

One of the most important aspect of “ease of maintenance” is the cost of adding new features. I call this extensibility. If I quickly write some code to satisfy today’s requirements without thinking about the future, it may cost me a lot to add new features two months down the line. Since no software metrics measure this factor, one has to pay special attention to ensure that your code is extensible.
Developers generally do not learn this unless they have worked on the same code base (and suffered the pain) for 3-4 successive product feature releases.

With the rate at which developers change jobs, this breed is difficult to find in India.
So how many developers in your team have worked on 3-4 successive feature releases of the same product? Leave a comment.