Software, “It’s not what we do”.
I get to visit with a lot of developers in a lot of different organizations. Sometimes those developers work for software companies, sometimes they don’t. More often they do not. Most IT professionals don’t work for software companies, after all, and custom software development in these environments is considered an “enabling technology” rather than a “core competency”.
One thing I have heard expressed in those places is, “software development is not our core competency, therefore recommendations around professional development practices don’t apply to us.”
Good, lord. Really, people?
This is akin to a Boeing corporate attorney claiming that he need not be competent because Boeing makes airplanes.
I don’t know where this absurd line of reasoning comes from, but I know why it is tolerated. It is tolerated because we don’t have the formal structures to hold professionals accountable the way we might hold an electrician, plumber, or physician accountable to being merely competent. If you are reading this post you probably make 3X the salary of a plumber, yet are held to a lower degree of professional accountability for your work.
This is sad, but it doesn’t mean that we need to pick up the mantle of mediocrity available to us. We can hold ourselves accountable for professionalism no matter where we work.
If the organization we serve specializes in jellybeans, services, software widgets, or any other industry, we are hired to bring our best game to the table. This is why they hire us, folks! We are supposed to know what we are doing, not making excuses for incompetence!
In summary, no matter what type of organization you work for:
- Yes, you need to use source control.
- Yes, you need to automate the build.
- No, you shouldn’t be releasing the assemblies compiled on your machine.
- Yes, you need to stop writing long methods and pay attention to code complexity.
- Yes, you need to buy your developers the best tools available.
- No, you don’t need to write your own logging framework.
- Yes, you should be practicing test first development.
- No, continuing to ship known defects is not acceptable.
- Yes, you should understand who your customer is.