What I am going to put here is nothing new or enlightening for a seasoned software developer, it’s just my trials and tribulations working through some heavily screwed projects over the course of my career.
So what are those software (mal)practices which sound death knell and ensue disaster? Well, here are my top recipes for embracing pain
1. Code Repetition – Remember DRY aka Do not Repeat Yourself. Even if you repeat a mere 3/4 lines of code in 10 odd places just pause and think over. Something ought to be fishy, try to put that repetition into a function, reuse the code. I have burnt my fingers fixing repeated lines of code in 10 to 100 odd places, even a full package of Java files being completely duplicated to another package. Just remain ruthless if you see duplication, it should never be there, don’t hesitate to select and hit del, even if your manager is going to fire you for that.
2. Intermixing logic – Or simply violating SRP (Single Responsibility Principle). Its really catastrophic to mix UI logic with business logic. It just makes the whole code very difficult to read/debug and even more difficult to change anything. Suppose you want a new UI for the same logic, you are screwed, you have to recode the entire business logic again or refactor the current code to separate out business logic from UI. In this aspect I need to point out a horrible technological offering from Java Stable – JSP. If not used carefully JSP spell death knell. It’s so easy to mix db calls/business logic and UI HTML into the JSP. But what we get out of this shortcut is a code mass which totally undecipherable, not at all debuggable and what more stack traces point to the dynamic servlet code line numbers of the JSP. I loathe JSPs and wish Sun never gave so much power to the naive user to intermix things and screw up life.
4. Looong methods – How long can a method be? 1000 lines, 4000 lines? Well I had opportunity to debug upto 10k lines of code in a method. My pea brain just could not hold on that and I just had to leave that and pray before I run those methods. I personally feel 50 is the max number of lines you can have, 50 is upper limit of tolerance, ideally a method need to be 10-15 lines of code in a well crafted software.
5. Exposing the internals – If you have class, don’t expose the internals of it to outside. If you maintain list of names as HashMap inside a class, don’t tell world that you are using HashMap. Just keep it with you and give neat interfaces to outside like
void addStudent(int id,String name)
void getStudentName(int id)
rather than using
In the latter case call can even modify the Map without you being aware of it and at later point if you are going to change the Map to a Student Class, you are screwed up because all those who are exposed to your internals need to be updated.
6. Building the code on
ArrayList, HashMap – ArrayList and HashMaps are good, but should be the lowest level of implementation never exposed out through public APIs or methods. I had tremendous experiences where a HashMap contains 10 keys, 1st key returns another HashMap which intern has 10 keys and each of those keys have ArrayList, Array, String, Integer etc. Then there were wonderful data structures like an Array of ArrayList. These kind of things drive you nuts and crazy, unless you debug line by line and print line by line its never clear what goes where. Class is the most powerful abstraction you have and try to encapsulate things within the objects and pass around objects rather than Lists and Maps.
8. Passion – (or lack of it) Majority of those who write code, do it for getting pay cheque at month end. Building code is cheap and easy. Anyone with a reasonable aptitude can do it. But crafting it to be readable, extensible, maintainable requires lot of pain, learning and rework. If you are not willing to take that pain, not willing to learn how to write testable software, then don’t just do it.