Gap analysis for a Software Produc t Team

‘Deceived’ - is the state of sincerely believing something which is false and baseless.

The more I engage in teams the more I have to fight against deception. A deception that we are good and high tech when most often managers in software rarely know and understand what and how to measure in order to gauge effectiveness of the team.

Software is not only meant to be executed, it is meant to be read, to be understood by others, to be maintained, to be deployed - Think about that.

I will attempt to list some basics without which some teams alarmingly keep on churning software - software that runs (and nothing else) but is worth garbage measured against what it should be.

1. A Clear Java coding guideline.
How long will a software team survive without a standard set of comment tags for classes and methods?
At the minimum these should have
@requires
@modifies
@effects
for all methods, which forces developers to think in terms of pre and post conditions for method behavior and the effects produced.

It drastically improves morale of new comers (with or without experience) when they look at the code base since they can now understand code.

The practice of throwing an already ugly code base at new developers without mentoring is ineffective. Moreover, they end up as faithful followers of the seniors in writing code without comments and tests. It only produces more 'blind men'.

2. A Simple to use but enforced Automated Testing practice at developer level

I mean 'automated tests' the way automated testing should be.

A group of developers have to be handed over (obviously by management) this task to create a customized test suite based on JUNIT that can send and receive Application requests and responses.

Feature Tests based on these then have to be checked-in into source repository for every CR/checkin. Let Managers override and accept responsibility for this if they feel that the checkin cannot be independently tested.

3. A dedicated build machine separately in all locations and an automated build cycle.

Again, please resist the 'this is that' syndrome of trying to equalize anything that you are doing now to what is actually being proposed. Builds on developer machines are fine only for that developer and with limited scope.

Build machines look at the entire product. They should download the entire source from source repository do a full compile, build and package. Then a complete fresh deployment is done including all EJBS and then a basic set of automated Test are run to determine state of the code. Error are notifies by email or whatever is required. Xdoclet is one effective solution to build package and deploy EJB on any target App Server including weblogic,JBOSS and websphere.

Any build solution should maintain build config information in one and only place (DRY = Don't Repeat Yourself).

4. Finally, get all employees on a company wide Instant Messenger that helps locating people by knowledge and expertise. So anyone knows whom to reach to ask questions related to 'specific features'.

So there are solutions in all these areas but none will succeed without management drive and planning.

This analysis is free but might just be the same you get from a paid consultant. The content speaks for itself.

Wish you all the best.

Compilers with hooks

I have been thinking on type safety and the excellent job that compilers do. Without letting you assume things let me state it clearly - one job compilers do well is helping us write 'correct' software by verifying type usage. This means that, if you define a type and later use that type then the compilers verifies whether all usage is conformant to the definition.

What is so great about this - everyone knows this? I think that tells me something about my job as a mature programmer. I should write code that checks code - help other programmers - by simply shouting every time a rule or practice has been violated.

I am thinking in the lines of being able to write java code that can be then plugged into the compilation process in order to verify applications within context. So each product team or company can then apply their rules and practices that simply shout on violation. The programmers are then supposed to just go ahead and correct code to get quietness.

I am interested in dynamic typing and one of the issues in dynamic typing is that the functional type of the instance is not its static type but is separate and distinct. So each object has functional type information. All this is pretty well known. I would like to envision a mechanism of verifying usage of objects even when their type is attached at instance level (runtime).

To simplify the problem in static typing all usage of objects of class C have to be verified against definition in C. In dynamic typing objects now have a static type of D (the dynamic type def) and then their functional type has to attach to each of these objects in order to verify their usage. If this can be done we then catch a lot of problems associated with using dynamic types and dynamic typing is useful in certain application problems. Application Configuration and XML parsing are two examples.