The quote is generally attributed to Phil Karlton. With a variation that's been added:
There are only two hard things in Computer Science: cache invalidation, naming things, and off-by-one errors.
More money is spent on maintaining software than on writing new systems.
It is more expensive to write and deploy crappy code than it is to write and deploy code that is "good" code. "good" depends on the context. But you have to write code knowing that someone else will be reading and understanding and changing it in the future. That's where most of the costs lie.
What you're generally talking about is the field of software engineering That is (IMNSHO), the coding implementation is just one part of the process of producing a part of an entire system that works correctly, is robust (handles failures appropriately), and is maintainable. Furthermore, the implementation happens in a context where time and resources cost money.
If you expect that the system you're working on will generally be thrown away in about a year, then the cost of doing line-by-line code reviews so that everyone on the team agrees and works to a particular standard is going to be much less than a system that you want to survive for a number of years.
If you are working on an airplane guidance system then the cost/benefit of code reviews is much different. Not only does your code have to be absolutely correct, when (not 'if') someone needs to change your code, it better be straightforward to make changes and not be so convoluted and brittle that any change will break it.
IOW, context matters. The cost/benefit analysis should guide you to what level of what standards are needed. Sometimes line-by-line code reviews are totally worth it and required. Sometimes they're not.
Version 1.0 of a system is much easier than version 3.5: in version 3.5 you have to deal with all of the mistakes that were made in all of the previous versions and all of the things learned since then and all of the changes in the world/business/area that have happened since then.
People have been thinking about and studying this and writing about this for decades. When developers start to grasp this, they have taken the first step to moving from "coders" to "software engineers."
I’m not sure if you’re comment is directed specifically at me (the author), but just in case it is:
The quote I’m talking about is not the infamous one you’ve given an attribution for. I’m talking about the variant which speaks to the larger of our industry’s problems today--i.e., people. One of the reasons this quote is magical is because it shows how outdated the original is.
Software engineering principles are generally not a match for today’s programmers given the industries they work in. If you haven’t already, I suggest you read Software Craftsmanship by Pete McBreen which will make clear some of the advances in thinking about software development in the last 25 years or so.
My point with this article is two-fold:
To highlight that it’s extremely important to pay attention to messaging when you’re in a position of authority.
To highlight that, for those of us who care about the notion of clean code, our thinking has evolved since the days that Kent Beck, Martin Fowler et al first showed us how to write better code.
You're right -- I haven't read Software Craftmanship yet. But now I will.
But I also think that maybe my definition of "Software Engineering" is more expansive. My view of Software Engineering includes people and their behaviors and wants and needs and humanness as a major part.
Teamwork is a critical part of pretty much every software engineering process. And so if the leader of a team is not a good manager or leader, that negatively impacts that part of the process. If the leader of a development team isn't able to determine what level of code review is appropriate -- if the leader is insisting on line-by-line reviews with very rigid rubrics and that is not appropriate, then that will negatively impact the team and the code developed. That is all part of the software engineering process.
So I totally agree with you that
"it’s extremely important to pay attention to messaging when you’re in a position of authority"
because that is part of software engineering. Everything involved in producing and deploying software -- whether it's writing it new from scratch or working with code that someone else wrote 5 days ago or 5 weeks ago or 5 years or 15 years... -- is part of software engineering to me. It's not just about writing code -- it's much larger than that.
Writing clean code is just one part.
And people are always part of the process. (developers, users, stakeholders, investors, ...)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
More money is spent on maintaining software than on writing new systems.
It is more expensive to write and deploy crappy code than it is to write and deploy code that is "good" code. "good" depends on the context. But you have to write code knowing that someone else will be reading and understanding and changing it in the future. That's where most of the costs lie.
What you're generally talking about is the field of software engineering That is (IMNSHO), the coding implementation is just one part of the process of producing a part of an entire system that works correctly, is robust (handles failures appropriately), and is maintainable. Furthermore, the implementation happens in a context where time and resources cost money.
If you expect that the system you're working on will generally be thrown away in about a year, then the cost of doing line-by-line code reviews so that everyone on the team agrees and works to a particular standard is going to be much less than a system that you want to survive for a number of years.
If you are working on an airplane guidance system then the cost/benefit of code reviews is much different. Not only does your code have to be absolutely correct, when (not 'if') someone needs to change your code, it better be straightforward to make changes and not be so convoluted and brittle that any change will break it.
IOW, context matters. The cost/benefit analysis should guide you to what level of what standards are needed. Sometimes line-by-line code reviews are totally worth it and required. Sometimes they're not.
Version 1.0 of a system is much easier than version 3.5: in version 3.5 you have to deal with all of the mistakes that were made in all of the previous versions and all of the things learned since then and all of the changes in the world/business/area that have happened since then.
People have been thinking about and studying this and writing about this for decades. When developers start to grasp this, they have taken the first step to moving from "coders" to "software engineers."
I’m not sure if you’re comment is directed specifically at me (the author), but just in case it is:
The quote I’m talking about is not the infamous one you’ve given an attribution for. I’m talking about the variant which speaks to the larger of our industry’s problems today--i.e., people. One of the reasons this quote is magical is because it shows how outdated the original is.
Software engineering principles are generally not a match for today’s programmers given the industries they work in. If you haven’t already, I suggest you read Software Craftsmanship by Pete McBreen which will make clear some of the advances in thinking about software development in the last 25 years or so.
My point with this article is two-fold:
You're right -- I haven't read Software Craftmanship yet. But now I will.
But I also think that maybe my definition of "Software Engineering" is more expansive. My view of Software Engineering includes people and their behaviors and wants and needs and humanness as a major part.
Teamwork is a critical part of pretty much every software engineering process. And so if the leader of a team is not a good manager or leader, that negatively impacts that part of the process. If the leader of a development team isn't able to determine what level of code review is appropriate -- if the leader is insisting on line-by-line reviews with very rigid rubrics and that is not appropriate, then that will negatively impact the team and the code developed. That is all part of the software engineering process.
So I totally agree with you that
because that is part of software engineering. Everything involved in producing and deploying software -- whether it's writing it new from scratch or working with code that someone else wrote 5 days ago or 5 weeks ago or 5 years or 15 years... -- is part of software engineering to me. It's not just about writing code -- it's much larger than that.
Writing clean code is just one part.
And people are always part of the process. (developers, users, stakeholders, investors, ...)