Why do Programmers Hate to Code? My Programming Philosophy Part 2
I would like to expound on my previous programming philosophy post (dated over two years ago).
Have you ever found yourself in the following situation? You have a task to accomplish that is just a little over your head. You have gotten a solution ready, but can’t quite get the last piece in place. You find an Open Source library that solved your particular problem because it was required for the library to work, however the library itself is not what you need. You just want to see how someone else solved the problem. Maybe it will give you an idea of how to solve it for yourself, maybe not.
I have had this situation myself a couple of times, so I delved into someone else’s code to find the answers. In each case I found (especially from Java Open Source projects) that it took hours trying to find where the heck in the object hierarchy the task actually gets done. Some object sends the information up the inheritance tree, where some parent actually encapsulates another library to do the task, where this library sends it up it’s inheritance tree to encapsulate other objects which each does a little of the task.
So why are programmers so adverse to actually writing the code to get tasks done. Do they all think of themselves as “Architects” and that code that actually does stuff is left to the “Implementer”? Is it that they are so steeped in the OOP philosophy (rammed down their throat in school) that they can’t think any other way to code? Paul Graham (one of the authors of Viaweb, and one of the creators of ARC) has suggested that it might do something with OOP making you look busy while you are not actually programming a solution. (See: Why Arc Isn’t Especially Object Oriented)
I think the answer includes some if not all of these ideas, but at the very heart of it comes down to the fact that programming is dull and the software developer wants it to be more exciting. This would explain why for each project certain programmers will spend lots of time re-creating hierarchies of taxonomies of objects to fit a new set of circumstances instead of using the old ones in the previous project. After all, for most programming tasks, defining how the code should complete the task involves more creativity and more brain power than actually writing the code to do the task.
I stand by my previous statement. If there is not a compelling business reason to code something in a particular way, then I will not. This includes Object Oriented Programming. There is no point to define an Interface or an Abstract Class if there is only one implementation of it. There is no point in creating an object that just encapsulates another library and passes the data to it to be processed.
Edited to Add: For me compelling business reasons to use a technology, like object oriented programming, would include: bug fixes (or adding) to the existing/legacy code-base; conforming to policy laid out by management; interfacing with other code in a larger system; and building my code so a team member can work with it and/or take the project over. I would in these instances make the case to management why I think that the code would be better suited to other architecture/technology choices.
