+972 52-548-6969
Great Code and Average Programmers
In the comments to this post, Hildo had this to say:
The problem with this is that the code written by excellent programmers like Eric will not always be understandable by coders in the lowr 50% of the bell curve. The code will be concise and well-designed, but as a result not like like the typical “write it all out” code that typical programmers churn out.
This matters because the code will have to maintained and enhanced by such programmers for the remainder of its life, which is likely to be far longer and far more costly than the development time.
I see this all the time at work ($VERYBIGCOMPANY). Programs that need to survive for a long time (5-10 years) are on purpose given to large groups of mediocre programmers, so the code will be at their level and can be maintained by them. Short-term high-priority projects are given to really great programmers, but if theu survive longer than expected, they often have to be rewritten from scratch 2-3 years down the road when requirements have changed fundamentally and the original developer is working on another important project.
This approach sucks. I do not doubt that it happens, but it has happened from the wrong reason. It sounds like the "really great programmers" are hackers, in the deregatory sense of the word. There is no way a good project would be replace in a 2-3 years just to get it to a more maintainable level for medicore programmers. By definition, this is not a good project.
I talked with a company that rejected just about everything I had to offer. The reasoning was that what we offered wasn't something that the average (or slightly less than that) programmer would know, and they were afraid of their stuff would not be able to maintain that. In the end, it got to the point where we did the math. Using smarter tools and working with higher level of abstraction would allow to deliver a higher quality system within a shorter period of time. Considerring that they were bringing new programmers to the company every couple of months at most, the cost of training would be negligible.
I could make them see the numbers, I couldn't get it through. "It is not the way we work".
Well, you work stupid.
Comments
Love your blog and I buy your arguments, but that's beside the point. Let me give you some perspective. I've worked as a sw-consultant in the financial business for a little over 10 years. This is the reality of the market. I see it all the time. The customer will get what they are willing to pay for, and that does not include anything they think is too hard to maintain for years using their own people. I don't intend to be rude, but you either deal with that or go find an ivory tower.
I had a small dose of this recently when I proposed using MonoRail on a project. Though, it was more of "we want technology that is standard" (i.e., ASP.NET/WebForms).
I personally feel that well-factored, well-designed code is more readable and maintainable, even by lower level programmers. Part of the idea is to demonstrate _intent_. Good code has more clarity (that's why it needs less comments, if any.)
Finally, I have seen lots of code written by average programmers that was nightmarishly difficult to understand and maintain. I have seen that on little jobs and multi-million dollar projects
Like Mathias said, that is just the reality of it all. That's how business want to operate because it produces lower costs in the short term. Even though the long term benefits should be obvious with a high abstraction, smarter tools, extensible design approach and whatnot, that just doesn't seem to translate to $ to a lot of decision makers. Its a shame, for sure, but its also the reality of it all. They love to bring in the intermediates to be able to maintain a system at lower overhead after the big dogs have already come in and implemented it. They just don't always understand the cost from a different perspective, which is the software and associated costs for it to evolve.
I think a lot of time people are faking the picture, by intention or ignorance. There are many programmers refuse to use a more scientific approach to find out the truth, thats how MS's sucker framework survive so long. Because people use their blind beliefs instead of their great brains to understand stuff. (It ends up their brain is depreciated anyway :( )
@Mathias,
I don't argue that this is not the way it works. I simply think that this is not a good approach.
I find that not using smart approaches ends up doing a lot of damage to the product, reducing the ability to work and increasing the amount of work required to handle bug fixes/new features.
I think that customers that choose this approach end up harming themselves.
Hey, I feel you. I'm on your side all the way, but some people just can't break habits or understand that there is a better way. We've had I've had two customers decide against using C#. The reason? They felt VB.NET was an "easier" language - or they did not want to bring in a "new" language (both VB6 shops). Another customer has more than one sw project manager that repeatedly refers to "unit tests" as developers who run the application on their machines manually (still after me thoroughly teaching them).
Why am I thinking of this Monty Python sketch?
http://www.richardpettinger.com/funny/blog/archive/2006/10/15/video_four_yorkshire_mans_sketch
Three New "Working with Data in ASP.NET 2.0" Tutorials Now Available [Via: Scott Mitchell ] Tip/Trick:...
Stupid or careful?
Adi,
Definitely stupid.
Did you read my post?
http://dotmad.blogspot.com/2007/03/customers-dont-want-cutting-edge-stuff.html
Adi,
Sorry, I didn't notice that it was a link.
Reading now.
Comment preview