When I started my career, the first thing I made up my mind about is I have to “Stand on the shoulders of giants”. From the very beginning, I tried to learn from the best coding practices, design patterns, case studies, books etc etc. In fact, there are so much materials around that one has to be overwhelmed! But there are some lessons that I had to learn the hard way. Although they are in the books, I didn’t realize them until I made the mistakes over and over again.
In this series of blog post, I’ll try to share them with the rest of the world. Note that these are not my philosophy, I just think they are the most important among all other principles.
Lesson 1 : Pareto’s Law – The 80/20 principle:
While the 80/20 principle is applicable to a lot of areas, I am only talking about the software modules and codes. If you are involved in a big project, You will see only 20% of the code is performing the core task, the rest 80% is just supporting codes. If you have 10 components in the system, only 2 of them is actually performing the task, the rest are just there to help the 20% (This applies if you group your functionality in a proper way rather than scattering them all around).
We software developers often overlook this, we often put our focus in the wrong place. One thing you need to think about is the Return of Investment. If you claim to be an engineer, one thing that an engineer does is Optimization and Trade Off. Say you are developing a plugin framework – the framework itself is much more important than the plugin. If you have limited time and you try to put equal effort on both of them, you will get none of them right. We always work with deadlines, we never get infinite time, so we have to effectively use that time.
Perfection takes a lot more time than getting something done. You have to make wise decision about which areas you need to perfect and which areas just need to work. Abstraction is the key here. If you have good abstraction, you can always go back and improve your code. I was watching this presentation by Eric Evans about “Strategic Domain Driven Design” for large project where he talked about the same thing. I was quite surprised how our view seemed kind of same! Well, Great men think alike 😉
Anyways, the point I am trying raise is that , we developers become too much obsessed with our code and technology and forget to think about the Deadline, estimation and all these stuff. If you don’t think about ROI (Return of Investment), your project is going to suffer from it. This will even make more sense when you think about Agile development, Changes is requirement and “Throw-away System” from The Mythical Man-Month(Another lesson I’ll talk about).
In the next post, I will talk about the Lesson 2: Abstraction
Lazy Programmer's Shortcut 