I have spent a large proportion of my career in software development working on green field projects. I find the activities involved in setting up these projects immensely rewarding. These activities include requirements gathering, evaluating developments in technology and software infrastructure, creating prototypes, defining logging, security and data access strategies, designing the domain model, and setting up processes and the application framework.
What I find less rewarding, is the development activities that flow on from that, but actually deliver the business benefit. By this I mean building the domain entities, DTOs, pages and forms for all the CRUD operations. There are tools that assist with this and take some of the effort out of this, such as NHibernate and the strongly typed views and templates in Microsoft’s MVC framework. But, at this point, by and large, the technical challenge and interest starts to wane.
Maintenance programming offers an entirely different environment. Sure, you are constrained by the architectural and infrastructural decisions made by those who have gone before you, but likewise, the vast majority of the system CRUD has also been done. The focus then, is on activities such as solving business problems, refactoring, performance enhancement, and perhaps even extending an application framework to support scenarios it was not originally designed for. All activities which require sound judgement, thinking and analysis.
I must concede that there are also maintenance activities that are less rewarding. Tasks such as forward and backward porting enhancements and bug-fixes, retrofitting internationalisation or logging, and of course, adding additional CRUD functionality.
So while the challenges are different, there remains plenty of opportunity for intellectual stimulation. Unfortunately, in my career, I have found the following axiom to be true:
But for me, that is antithetical with software development as a discipline and as a profession. It is the analysis, investigation, problem solving, in short, the necessity to “think” that makes software development rewarding, whether in green field projects or maintenance projects. In my opinion, it is that degree of thought that makes the distinction between a professional software developer and a ‘code-monkey’.
What I find less rewarding, is the development activities that flow on from that, but actually deliver the business benefit. By this I mean building the domain entities, DTOs, pages and forms for all the CRUD operations. There are tools that assist with this and take some of the effort out of this, such as NHibernate and the strongly typed views and templates in Microsoft’s MVC framework. But, at this point, by and large, the technical challenge and interest starts to wane.
Maintenance programming offers an entirely different environment. Sure, you are constrained by the architectural and infrastructural decisions made by those who have gone before you, but likewise, the vast majority of the system CRUD has also been done. The focus then, is on activities such as solving business problems, refactoring, performance enhancement, and perhaps even extending an application framework to support scenarios it was not originally designed for. All activities which require sound judgement, thinking and analysis.
I must concede that there are also maintenance activities that are less rewarding. Tasks such as forward and backward porting enhancements and bug-fixes, retrofitting internationalisation or logging, and of course, adding additional CRUD functionality.
So while the challenges are different, there remains plenty of opportunity for intellectual stimulation. Unfortunately, in my career, I have found the following axiom to be true:
“You can take a programmer to a code base, but you can’t make them think.”
But for me, that is antithetical with software development as a discipline and as a profession. It is the analysis, investigation, problem solving, in short, the necessity to “think” that makes software development rewarding, whether in green field projects or maintenance projects. In my opinion, it is that degree of thought that makes the distinction between a professional software developer and a ‘code-monkey’.
Comments
Post a Comment