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.
Being one of those persons that works in non-it related bussines I can say that I do want to adhere to good practises. But I can see that for some it would be hard to convince their non-IT superiors. But in the end good practises pay themselves back and bad practises cost money.
Hear, hear, David. I’m a long time defendant of the same fundamental idea that you described here. In my previous job I tried for at least 3 years to instill many of these practices and attitude in my working group. Ultimately I realized people agreed with the general idea but preferred to sit and watch me entertain them while I tried to climb wall after wall. At that point I had to move on.
I hear this excuse almost every day at work. I don’t understand how people can use it to justify poor workmanship.
Been on both sides as the internal developer and as PM/analyst. One organization, where my team handled customer support, I would be on conference calls with a software development team up and question about development practices… all you would hear was crickets chirping in the background… (I think the answer about source control that finally came up was the ‘gatekeeper’ method, which was never conclusively established as anything beyond programmers yelling out to surrounding cubicles what module they were worked on)
If I was suggest some healing steps when you find yourself in that situation:
*Centralize source code
*Bring tools and external dependencies up to current, supported versions
*Document build release process in at least Word docs
I find that these steps make it the tasks of build automation, adopting source code control, etc. more approachable.
I wish my non-IT bosses would accept the practices you preach.
I wish I knew where developers earn 3x what plumbers earn. Not here, that’s for sure…
I’ve seen a few cases where the developer wanted to write tests, but the manager (tech) said it was a waste of time and they don’t support tests.
And 99% of the developers on that team don’t write any tests and spend their whole day debugging with 3 instances of Visual Studio open.
When I walked in and said ‘do we have tests’ – a few guys looked up and said ‘no – *wish* we did’ – and then went back to debugging 🙂
So the entire team didn’t buy into tests and the project mentality was ‘we are behind and out of money on this project so just keep debugging!’
One item I am unsure about and would appreciate some understanding is the 3rd point “you shouldn’t be releasing the assemblies compiled on your machine” – Is it considered a better practice to take the assemblies/files from the automated build machine for deployment? What about doing so makes it a better practice?
The build machine is a controlled, understood, common, repeatable environment. Your desktop dev machine is not. Your box may have version C of FooLib, while somebody else has version A.2. If you deploy your copy, then how do you know what dependencies you also need? Also, how do we know if you actually checked everything needed to do a build into the source control system?
Deploying from the build machine means you know EXACTLY where everything came from, you can reproduce EXACTLY the dependencies you need, and when you debug you know you have the EXACT and complete set of stuff to work on.
@Chris – Thanks for the explanation. My thoughts were along those lines.
David, I basically agree with you but I think you’re simplifying a bit. Let me try to explain: in non-software business frequently happnes that shipping a “buggy and dirty” software change can save the company milion $$$$. When speaking about non-safety-critical software systems (software onboard the aircrafts is another story!), the short term return on investment of a quick (and probably dirty) solution is high. However, long term, this approach may lead to an instable software environment that may seriously impact future development speed, software stability, quality in general. It’s difficult to have an estimate of this impact, probably that’s why I’ve never seen it as a component of the software costs.
Basically we have two strategies:
1) to satisfy imminent business needs shipping a “good enough” solution
2) or let the customer wait for a robust and excellent system.
Since economy in general has cycles, non software company should focus on the 1st approach in the high cycle, when a new functionality on time can determine the success of the company, and on the 2nd one in the low cycle, when there’s more time to “invest for the future” refactoring (rewriting in some cases) the previously created poor software.
However what I’ve seen so far is that, during the lows, companies decide to cut-costs indiscriminately instead of investing for the future.
Not to burst your bubble but the most important aspect of development is delivering something that works and that people find useful, not HOW its developed. At the end of the day, that is what is important, not a TDD’d CI’d piece of garbage that no one wants. We dont use continuous integration, dont subscribe to test first development/TDD, and we DO deploy from dev machines. We dont have a problem and make over $1M a month profit with a few developers.
@Dean –Ad crumenam, Ad crumenam…
Delivering something that works and is useful IS SOLELY based on HOW it’s developed. I assume that use source control (since you didn’t knock it on your post). Why not just put everything in a folder on a shared drive? — because it obviously makes sharing changes easier.
And in the same fashion implementing CI (or at minimum a repeatable build script) makes deployments easier. Not only that, but how hard is it to implement? Why would you want to add unnecessary risk from deploying from developer’s machines when the alternative is just as easily done???
@Dean
I don’t labor under the false impression that fortunes aren’t made on piles of crap.
Windows 95.
We done here?
@Daniele Spinosi
Good enough in feature set is a very Lean and profitable idea. That does not equal or even influence good enough in quality of the features that you do choose to implement.
If we are so concerned about the quality of items being bulletproof and NASA ready before they are unleashed on the public why so many validation errors on your site?
Clearly, you should have a validation check as part of your “deployment” process to ensure such quality errors are avoided. Dont worry about writing your next blog post (who cares about the output, we’re after quality here!) youll need to spend the time fixing this error instead.
You can see where I am going with this I hope.
http://validator.w3.org/check?uri=https://elegantcode.com/2010/08/09/software-its-not-what-we-do/comment-page-2/;accept=text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8;accept-language=en-us,en;q=0.5;accept-charset=ISO-8859-1,utf-8;q=0.7,*;q=0.7