> What do you think is the root cause of crap code?
I agree with Stroustrup's answer in the above mentioned interview:
"... the real problem is that "we" (that is, we software developers) are in a permanent state of emergency, grasping at straws to get our work done. We perform many minor miracles through trial and error, excessive use of brute force, and lots and lots of testing, but--so often--it's not enough."
I also agree with his solution to the problem:
" ... educate our software developers better, use more-appropriate design methods, and design for flexibility and for the long haul. Reward correct, solid, and safe systems. Punish sloppiness."
as well as his view on impossibility to solve it, given the current circumstances:
"In reality, that's impossible. People reward developers who deliver software that is cheap, buggy, and first. That's because people want fancy new gadgets now. They don't want inconvenience, don't want to learn new ways of interacting with their computers, don't want delays in delivery, and don't want to pay extra for quality (unless it's obvious up front--and often not even then). And without real changes in user behavior, software suppliers are unlikely to change."
So, as it turns out, in the end it is the user's fault we are making crappy code - you get what you paid for. It takes time, people and money to make good software. If the market was willing to bear the cost of good software, there would be plenty of it all over the place.
> I think the often-quoted "research" about differences in > programmer productivity/effectiveness isn't really valid. > What was actually measured? Was it based on production > code, or a toy problem. Was maintenance, documentation, > flexibility etc considered? In other words, you have to > come up with a comprehensive definition of programmer > "goodness" and measure it.
I often wonder if this is an intractable problem, at least for the time being. How can you measure how easy something is to maintain without having to maintain it first? And even with a maintenance history, you'd need a fairly large set of distinct projects that used similar methodologies to get a meaningful answer. I have never even seen a non-trivial production system that used one single methodology over a significant period of time. I just don't think we have the tools to analyze code with the required level of sophistication.
> > What do you think is the root cause of crap code? > > I agree with Stroustrup's answer in the above mentioned > interview: > > "... the real problem is that "we" (that is, we software > developers) are in a permanent state of emergency, > grasping at straws to get our work done. We perform many > minor miracles through trial and error, excessive use of > brute force, and lots and lots of testing, but--so > often--it's not enough."
I agree that that is why some developers (I call these good developers) sometimes create crap code but I don't think this is universally the reason. There are many people who don't see any value in good code. I can't count the number of times that I've read or heard statements that amount to "what difference does it make if it works?" and arguments about how all working solutions are equivalent. You can find them all over the Artima forums. There are many of these developers in our midst and they produce crap code at an astounding rate. The worst of these are primadonnas and contractors who never have to maintain the code they write.
There is crappy code because there is crappy thinking. Good thinking requires practice and effort. In the same way that somebody might enjoy a game of Golf by Tiger Woods and cringe when seeing a rookie take 20 hits to get the ball in the hole, programmers enjoy good code and suffer the bad one. Businesses on the other hand usually don’t care much about the code. They don’t care how it is done, just how much the golfer gets paid and how long it takes him to get all to agree on where the hole is.
> There are many > people who don't see any value in good code. I can't > count the number of times that I've read or heard > statements that amount to "what difference does it make if > it works?" and arguments about how all working solutions > are equivalent. You can find them all over the Artima > forums. There are many of these developers in our midst > and they produce crap code at an astounding rate. The > worst of these are primadonnas and contractors who never > have to maintain the code they write.
This really falls into ethics - a portion of any certification is (if not, it should be) dedicated to the ethics of the trade. While this can not enforce a morality of a certified person, it can at least make the defense of "I wasn't aware" type non-viable.
> > There are many > > people who don't see any value in good code. I can't > > count the number of times that I've read or heard > > statements that amount to "what difference does it make > if > > it works?" and arguments about how all working > solutions > > are equivalent. You can find them all over the Artima > > forums. There are many of these developers in our > midst > > and they produce crap code at an astounding rate. The > > worst of these are primadonnas and contractors who > never > > have to maintain the code they write. > > This really falls into ethics - a portion of any > certification is (if not, it should be) dedicated to the > ethics of the trade. While this can not enforce a morality > of a certified person, it can at least make the defense of > "I wasn't aware" type non-viable.
But it's not necessarily that these people are unethical. They just don't see any value in 'good' code. Moreover they don't see what is good about good code.
I really don't see how good code can be certified. It's kind of like being a certified writer. Other than grammatical mistakes or use of things like passive voice, what non-subjective criteria can you use to gauge the quality of a piece of literature? If you don't think this is a valid analogy, could you explain in what way?
The one example of this that I can think of was the push for structured programming. It was very successful. So successful that we take it for granted as it's baked into modern languages. But we still have bad code.
It's easy to say we will certify programmers but how will that certification resolve this issue?
Personally, I think treating programming as a trade with apprentices, journeymen, and master developers would be more effective. The problem is that masters are few and far between.
> But it's not necessarily that these people are unethical. > They just don't see any value in 'good' code. Moreover > r they don't see what is good about good code.
Sure they are unethical. Just like littering the highway is unethical. Your neighbors have to live in a polluted world and someone has to come behind you to clean your mess while you don't see any value in being tidy? That is unethical.
> I really don't see how good code can be certified. It's > kind of like being a certified writer. Other than > grammatical mistakes or use of things like passive voice, > what non-subjective criteria can you use to gauge the > quality of a piece of literature? If you don't think this > is a valid analogy, could you explain in what way?
There are multiple ways how the quality of code can be improved and certification is one that IMO should contribute to it. there are other ways, such as education, coding style standards etc...
> Let's look a this with less a > human-as-center-of-the-universe point of view. If one > wanted to understand basic truths about animal kingdom, > would it make sense to ignore actual animal behavior or > label it as "out of touch"?
We are out of touch as a society because we have become circus animals, rather than the ones living freely. Since the circus master dictates it (money makes the world go 'round) to us, we must have air-conditioned living rooms and hundreds of TV channels even if we can only watch one at a time (a Seinfeld says, we don't want to know what's on the TV, we want to know what else is on the TV) and even if it means ruining a building of historic value. The sad part is that the examples I gave above are benign - nearby the place I mentioned, about 30 years ago, someone decided to bulldoze ruins of an ancient Roman city in order to build a chemical plant. If that is not "out of touch" I don't know what is.
> If, in practice, architecture > doesn't resonate with the majority of people living with > it, it has failed its mission. It's essentially not > fulfilling its customer requirements.
> I agree that that is why some developers (I call these > good developers) sometimes create crap code but I don't > think this is universally the reason. There are many > people who don't see any value in good code. I can't > count the number of times that I've read or heard > statements that amount to "what difference does it make if > it works?" and arguments about how all working solutions > are equivalent. You can find them all over the Artima > forums. There are many of these developers in our midst > and they produce crap code at an astounding rate. The > worst of these are primadonnas and contractors who never > have to maintain the code they write.
Hey, watch the contractor comments! :-) (Actually, I'm in my last 2 days as a contractor. On 7/30 I go back in-house and am looking forward to it.) Although I agree that contractors tend to be mouse cowboys, there's plenty of crap code written on both sides of that divide.
It's more than just individuals though. Individuals write the code, true, but the mentality of 80% is good enough is social. I've heard of one large retailer who puts code into production when it meets 80% of the requirements. We accept everyday products not of the highest quality but at a cost we like. Does anyone buy their kitchen tables from a local woodworker anymore? Shoes from a cobbler? It seems like there's some sweet spot between cost and acceptable levels of shoddiness modern culture has tapped into. Tapping into this sweet spot is what allowed several software empires to form.
I'm playing "Devil's Advocate" here. Everytime I get stuck with indecphirable code I get upset too. My point is that it's not just our field. It's social and I don't have the foggiest idea how to change it.
> Personally, I think treating programming as a trade with > apprentices, journeymen, and master developers would be > more effective. The problem is that masters are few and > far between.
Wasn't there a book written by Peter McBreen about this?
> Sure they are unethical. Just like littering the highway > is unethical. Your neighbors have to live in a polluted > world and someone has to come behind you to clean your > mess while you don't see any value in being tidy? That is > unethical.
It's only unethical if you know that what you are doing is wrong. Personally I think that this is the majority of the problem. There are probably a good portion who realize it but rationalize it but I believe that most developers, once they understand the cost, will clean up their act, if you'll forgive the pun.
> There are multiple ways how the quality of code can be > improved and certification is one that IMO should > contribute to it. there are other ways, such as education, > coding style standards etc...
I'm not against certification. I'm just not sure it will resolve all code quality issues. There are a lot of really adequate and even excellent developers that know exactly how to make things work but don't see any value in organization and making things easier for maintenance. They see this is as a waste of time that's driven by people with OCD.
> I'm playing "Devil's Advocate" here. Everytime I get stuck > with indecphirable code I get upset too. My point is that > it's not just our field. It's social and I don't have the > foggiest idea how to change it.
As Lou Holtz said: If it's worth doing at all, it's worth doing well. Changing yourself is hard (but doable). Changing other people is impossible. So, the only thing anybody can do is change your ways if they are no good. That will influence the people around you.
> Hey, watch the contractor comments! :-) (Actually, I'm in > my last 2 days as a contractor. On 7/30 I go back in-house > and am looking forward to it.) Although I agree that > contractors tend to be mouse cowboys, there's plenty of > crap code written on both sides of that divide.
I don't want to paint with too broad of a brush but I've dealt with a lot of contractors who think their poop doesn't stink. But I've seen this attitude with anyone who doesn't have to work with existing code. Basically, my theory is that developers who think that maintaining code is easier than writing code from scratch are more likely to not get the value of well-written code.
> It's more than just individuals though. Individuals write > the code, true, but the mentality of 80% is good enough is > social. I've heard of one large retailer who puts code > into production when it meets 80% of the requirements. We > accept everyday products not of the highest quality but at > a cost we like. Does anyone buy their kitchen tables from > a local woodworker anymore?
Surprisingly, yes. Woodworking is a fairly lucrative venture. There's a lot of automation, though. I think you'd be hard pressed to find a professional workworker that doesn't have a lot of expensive power tools.
On a side note, my father was telling me something rather interesting about manufacturing. He was saying that right now, the cheapest place in the world for them to outsource machining is Italy. And the places that they are outsourcing to are mom-and-pop shops where the mother does the accounting and the father and son(s) do the machining. This is possible because of high level of automation they use.
Previous Topic
