Professionalism
I was inspired by this talk from RailsConf given by Robert "Uncle Bob" Martin. It's a really entertaining talk and you should check it out if you haven't already.
During the talk, the topic of professionalism came up and what it means to be a "professional software developer" (maybe 2/3 of the way through). Professionalism in software development is a topic that's not well defined and certainly has different meanings to different people.
Can you be considered a pro, for instance, if you don't provide a set of automated tests for your code? What if you don't use source control? Do you feel the need to always create a custom build file (make, ant, or maven script) so you can build independent of an IDE? Do your "professional" standards change depending on if you're creating "prototypes" rather than designing code for production?
I know which things I strive to do on every project I work on. But the standards for the teams I work with vary wildly. And this fact alone leads me to question why. Can't we do better?
Doesn't every application need some level of testing? Shouldn't these tests be automated and built into the fabric of every piece of code? Personally, I don't think the benefits of having an automated test suite can be questioned anymore. Same with source control.
Additionally, I feel every project should replace the build file generated by an IDE with one of their own for this simple reason - maintenance. Have you ever looked at the Ant scripts generated by Netbeans? It's enormous - and it has to be to support the wide range of functionality Netbeans allows Java projects to do, like generating code for WS clients for instance. At a minimum, developers should take out all the extraneous (unused) targets and move references to IDE-specific libraries needed to build the project under their own control (treat them just like application dependent libraries). Without this measure, you're locked into a specific IDE and often a specific version of the IDE. By taking this simple step, you can upgrade your development tools without fear that the system won't build.
Excuses not to do the things listed above often fall under the veil of, "We're developing a prototype. We need to do it rapidly and we can't slow down to take on the overhead of automated testing or configuration management". My response is, why not? Isn't this code going to be "delivered" anyway - if not to a client than just internally for evaluation. And really, when is the last time a really cool prototype hasn't been immediately folded into the production code. The overhead to doing these tasks is minimal compared to the time spent repeatedly doing them manually.
All I'm really saying is there are a basic set of things - source control, testing, and repeatable builds - that are common to any software development effort regardless of scope or technology. I'm tired of having the conversation about not only how, but if we're gong to do these most basic things on every new project I join. As a profession, we're better than this (at least we should be). At this point, it's wasteful to have these discussions time and time again. I don't think we can consider ourselves true professionals until we agree to deliver these most basic pieces of functionality for every piece of software we deliver.
During the talk, the topic of professionalism came up and what it means to be a "professional software developer" (maybe 2/3 of the way through). Professionalism in software development is a topic that's not well defined and certainly has different meanings to different people.
Can you be considered a pro, for instance, if you don't provide a set of automated tests for your code? What if you don't use source control? Do you feel the need to always create a custom build file (make, ant, or maven script) so you can build independent of an IDE? Do your "professional" standards change depending on if you're creating "prototypes" rather than designing code for production?
I know which things I strive to do on every project I work on. But the standards for the teams I work with vary wildly. And this fact alone leads me to question why. Can't we do better?
Doesn't every application need some level of testing? Shouldn't these tests be automated and built into the fabric of every piece of code? Personally, I don't think the benefits of having an automated test suite can be questioned anymore. Same with source control.
Additionally, I feel every project should replace the build file generated by an IDE with one of their own for this simple reason - maintenance. Have you ever looked at the Ant scripts generated by Netbeans? It's enormous - and it has to be to support the wide range of functionality Netbeans allows Java projects to do, like generating code for WS clients for instance. At a minimum, developers should take out all the extraneous (unused) targets and move references to IDE-specific libraries needed to build the project under their own control (treat them just like application dependent libraries). Without this measure, you're locked into a specific IDE and often a specific version of the IDE. By taking this simple step, you can upgrade your development tools without fear that the system won't build.
Excuses not to do the things listed above often fall under the veil of, "We're developing a prototype. We need to do it rapidly and we can't slow down to take on the overhead of automated testing or configuration management". My response is, why not? Isn't this code going to be "delivered" anyway - if not to a client than just internally for evaluation. And really, when is the last time a really cool prototype hasn't been immediately folded into the production code. The overhead to doing these tasks is minimal compared to the time spent repeatedly doing them manually.
All I'm really saying is there are a basic set of things - source control, testing, and repeatable builds - that are common to any software development effort regardless of scope or technology. I'm tired of having the conversation about not only how, but if we're gong to do these most basic things on every new project I join. As a profession, we're better than this (at least we should be). At this point, it's wasteful to have these discussions time and time again. I don't think we can consider ourselves true professionals until we agree to deliver these most basic pieces of functionality for every piece of software we deliver.
Comments