Non-indexed foreign keys

Let me start my first accepting a misconception which I had till very recently. I sort of always assumed that foreign keys are always indexed. A little more digging revealed that Oracle, DB2 and even SQL server does not create an index for a foreign key automatically. So it has to be explicitly done.
We all know indexes has cost associated to it. Apart from using the storage space, it has to be maintained by the database on inserts and updates but still it is very good idea to create an index for a foreign key and especially when

• We have a use case where deletion of the parent row cascades into deletion on the child table. Otherwise it will lead to a full table scan of the child table for each parent row deletion.

• We frequently join parent and child tables. Otherwise it will have a performance impact.

So basically a little bit of a trade off as what we really want to do but in general it is always a good idea to have an index on a foreign key.

But does all this have any impact on how we do our Hibernate mappings, yes for sure. So for example if we decide to not index a foreign key, then

• Be careful while using : on-delete=”cascade” even though the database has a support for it

• Always specify lazy=”true” to prevent a join and eager fetch of the child rows.

Now what is this Git?

It is an open source version control system. So why do we care? We already have subversion. Here are few points which might get you interested.

It is a distributed version control system – which means every user has a complete copy of the whole repository locally on his/her box, I mean everything with complete history and thus the ability to track the revisions without going to a central server. It brings in the advantage of looking at a file history offline and in no time. It also brings in a side effect of having the repository backup at so many places.

Branching and merging comes in naturally – Since every check out in a way, is a sort of branching by itself, the whole process of branching and merging for Git can be compared to checkout and commit for may be subversion.

Offline and Extremely fast – Remember there is no network latency as everything happens locally, as the local copy on a box is a full-fledged repository. So no matter what we are doing, committing the changes, looking at a previous version of a file, looking at the history, performing a diff or anything else we do not need a network connection to the central server and it is damn fast.

Does need a small space – If every user has a complete repository on his/her local box, so obviously there is a concern for the size of it. Fortunately the way it is packed it is much smaller in size then may be subversion.

Not yet good support for IDEs – Not yet quite there to support most of the features from IDEs like eclipse or may be a windows explorer extension which we have for subversion. Although it does provide command line tools and graphical interfaces like git-gui

Tracking binary files – Git considers each merge of a binary file as a new file and thus do not support tracking and history for such files.

If these are not enough to arouse the interest, may be looking the projects which uses Git for their source code management might as well.

http://git.or.cz/gitwiki/GitProjects

Waste Elimination

Waste by definition, is garbage or rubbish and elimination of it quite literally means removing the bad, rotten, stinking practices from our software development process and code smells (a side effect of not eliminating the rubbish) from our implementation.

When we talk about lean manufacturing or more precisely eliminating the waste, then essentially what we are talking about is

• Delivering what makes sense to the customer and nothing more, as anything more is a waste. Try and help the customer distinguish between what he really needs against what he might need.

• Keep paying off the technical debt as soon and as much as possible. I consider paying off technical debts as synonymous to eliminating waste.

• Keeping a constant flow of work and working at a sustainable pace, eliminating the chance of dip in productivity, quality and motivation.

• More lines of code when less can do, is a waste. How often we have looked at a big massive codebase and thought to ourselves. What a waste? Get rid of it and every time I have a done it I have felt very good about it. Just think of it as if removing even few grams of weight from your backpack while travelling on an adventurous trip. Code light and it will definitely pay off

• Eliminate the artifacts which states what we are going to do, by really doing it. Non working, out dated artifacts is something we should always avoid

• Eliminate specialist roles as that would promote collective ownership and passion to collectively work for the success of the project.

Sometimes it helps to think Negative

Sometime not being an optimist pays. It pays when we want to do risk analysis for a project, it pays when we want to do code reviews and it definitely pays when giving the feedback.

Risk Analysis : I guess we have to play a bit of a critic for our own application to really realize the potential risk very early in the project and be able to do the risk analysis and mitigation upfront. Not knowing the risks and not analyzing the application critically may turn out to be the biggest risk eventually. May be knowing about them and playing with our worst fears will lead us making steps to cut down the possibility of them getting true.

Code Reviews: Being critical when doing the code reviews and while pair programming helps in improving the code quality and code design. It might get a little touchy when someone points to a problem we feel we did a good job at, but please keep in mind it is not about being negative to the person who implemented it but about being constructive in improving the coding best practices and code quality. Thumb rule while doing the code reviews hate the bad code not the coder.

Feedback: Think negative about the process, about the people and about the company. If we are not doing it we are not really helping us and everyone around us in learning and improving.

Non Technical Techies.

This is exactly what they are. I have come across so many of them already that it is not merely by chance for sure. I am not talking in terms of their skills or knowledge but mostly in terms of their attitude and outlook.

Looks like being in a technology division or churning out code day in and day out (yes this is exactly what they think they are doing) is just by chance and not by choice. Let alone feeling passionate for what they are doing, they seem so disinterested as they feel it is the way it has to be till they start leading a team or get into project management.

This is what I get to hear. Writing code is easy, anyone can do it. I want to go beyond it. Yes I agree anyone can do it but does that anyone can write good quality readable and maintainable working piece of software, very few. How many really want to perfect the art of designing and writing code.

It is just like a craftsman instead of trying to perfect that craft and setup an example of showing how it should be done wants to lead (read manage) a distant-to-qualify-even-decent and still learning group of craftsmen which themselves are not proud of what they are doing. Sometimes it is hard
for me to make people believe that I am still coding after 11 years and I really enjoy doing it and enjoy growing even more technically.

Learnings from Interview Discussions

When I am interviewing someone I am not hiring a guy to work for the company I work for, but instead a possible colleague. It is never about the years of experience it is more about the ability to learn and the passion for the work. The idea is never to look out for a match for the requirement but look out for potential, drive and skills beyond the requirement at hand. Few things topmost in my list to look out for beyond just the technical know how in general.

Article on TSS

Agile software development has its own manifesto which lays out the values and principles of agile process. I have tried to look beyond (or may be just deeper into the meaning of) the essential four value statements in my article at TSS

http://www.theserverside.com/news/thread.tss?thread_id=48140