How many times have you banged your head against the monitor or seen others doing so when the poor dumb machine goes dumb literally!? Must be a lot of times for most developers. If not, you are a blessed child and you need not read further :).There is no use if you keep hitting the ENTER button or keep yelling at your machine when the machine cannot support what you want it to do… Now-a-days, companies are after new languages and technologies like RoR, Scala etc to improve developer speed. They have started following agile methodologies and hiring expensive coaches; paying a lot for agile certifications (really a lot 😦 ). Yes, all of these have actually improved efficiency. But in the thick of such ‘big’ things, aren’t they missing out basic stuff which will enhance developer efficiency? For instance, is it not a basic necessity to have a proper work environment, proper infrastructure that can support such ‘big’ things?
Latest technologies like RoR, Scala and Closure got quite a lot of craze based on one important point – “Less lines of code so quicker development”. All big companies especially service providers are after training their employees on these technologies. Even they were ready to compromise with performance in terms of speed and resource usage. Yes, this is perfectly makes sense as the cost of developer is higher compared extra server to compensate the performance.
How many lines of code do we really type in a day? Let me say 400 or 1000? If you are actually writing 1000 lines of code in a day, really there is some issue (this is a separate discussion altogether which I dont want to talk here). So how much time you are saving? How much money company and developer spending to attain that extra speed? Instead why not they fix few basic things at hand
Provide them right hardware
Developer should pause only to think of logic not for his poor system to respond his key strokes. Many corporate in India try to save few thousands by buying lower-end systems. Because of such systems, one might lose 30 mins on an average. Not just that it spoils the rest of the work. So 30 mins per day is like 10 hours a month and 120 hours a year. Even if we say average hourly rate is Rs. 800, total loss is 120 X 800 = 96000. Using this money one can buy the best laptop in the market. I am sure this is not known to the management. But they are still ignorant. Is it because those hours getting billed from the customer?
Invest time to make the work environment right
One thing I have observed with many legacy (also new projects) and interestingly with many agile teams, is setting up the work environment itself takes a day or two. Also deployment and build infrastructure were in real bad condition. Teams some how focuses more on delivering features. And also there is a fear of keeping team idle as revamping the work environment might need a code freeze ( alternatives are available). Initially it might take sometime and might feel non-productive to business, but if you calculate the time we lose with every build and every time a new developer joins, this is nothing. For example there are still so many teams who can’t build the code on their local or build using age old tools like RAD and cruise. Why not spend few days and move to new build tools like maven and jenkins.
Craftsmanship over framework skills
Just like agile principles, here I mean we should value craftsmanship more than learning features of framework. In an enterprise project 80% of the code we write is normally framework agnostic. Remaining 20% only framework related. If we don’t have command over writing good code, it doesn’t matter what technology you use.
Choose right tools
This is age of automation. So tools play a crucial role in automating rudimentary tasks and also doing things quickly if not automated. For example: Subversion is history, git is future. You can switch between stories and collaborate well and efficiently with git compared to SVN. A right CI tool to take your code to integration, run functional testing and then to prod.
There are more possibilities based on context and nature of project. Would love to hear more and any suggestions on above practices.