Gregor Hohpe on how good code goes wrong

Discussions

News: Gregor Hohpe on how good code goes wrong

  1. Gregor Hohpe on how good code goes wrong (34 messages)

    During his keynote address at The ServerSide Java Symposium in Las Vegas, Google Inc. software architect Gregor Hohpe urged developers to take advantage of the expressiveness of Java and write code for people rather than machines.
    In a facetious take on software developer paranoia, he suggested: "Maybe the janitor comes in during the night and messes up our code?"

    As Hohpe sees it, code gets messed up for far more mundane and preventable reasons. Principal among them is that sloppy code begets sloppier code. His theory is that if the initial developer of an application doesn't take care to make his code clear and logical to any programmer that reads it, Pandora's box pops open.

    The sequence of events Hohpe outlined begins with the developer writing code that is serviceable for the application – it runs okay – but the code itself is idiosyncratic and hard for another programmer to understand. Then along comes a programmer doing maintenance a year after the application goes live. The code appears to be a convoluted mishmash.

    Threaded Messages (34)

  2. It is an article of faith that every software development team only hires the best and the brightest programmers

    I don't know which company can afford it. Most of them hires cheapest developers available.
  3. I am surprised to see that such a trivial matter is put up for discussion.

    Sad
  4. Its not trivial[ Go to top ]

    I don't think this is trivial. I have to struggle through badly written code on a daily basis. Only in some projects there is really time (or knowledge) to educate people enough to get good code from the start. Failing that, only in rare occasions there is time to correct bad code.

        Erik.
  5. I don't think this is trivial. I have to struggle through badly written code on a daily basis.
    Who doesn't? Only those who are lucky enough to work on small dedicated teams.

    I think it would be a much more interesting article to face the fact that crap code and low-level developers are the staple of corporate development. The leaders in our industry whine about this a lot but it is a fact of life and it won't improve due to economic forces. As long as a corporation can pick up a six-pack of developers from Walmart that will work for 50% of what a talented and experienced developer would work for there will be crap code. It doesn't matter that statistics show the project will take 10x as long or that maintenance costs will be through the roof. I've yet to meet a corporation where those concerns matter to anybody above IT manager (if that).

    Another post was truthful in that the majority of crap code performs similar to quality code. I'd be interested in figuring out how to use existing frameworks to better localize the crap code to small crap islands (crapplets?). Early n-tier development did this by letting the so-called junior developers do the 5000-line-per-JSP programming while the experienced developers worked on the server. This was great until people started expecting more usable web interfaces.

    I have yet to see a software process or framework that tackles this issue realistically. They have "roles" but they don't specify degrees of capability. When 80% of your team thinks threading concerns are when your clothes start to wear out how do you best place them within a project?

    I think it would be fascinating to see a software framework that specifically breaks apart concerns so that you can use your A, B, C, and D developers to the best of their abilities while minimalizing the impact of the crap code that the less capable will crank out.

    I don't want to hear any feedback about how you should just get rid of the junior programmers. They have families, they have to eat, and realistically, if downsized, the more expensive developers will get the boot first. Our industry has to figure out how to best utilize the majority of its C and D-level developers. We can't make them all project-managers.
  6. We can't make them all project-managers.
    Like thats better than having them coding.
  7. We can't make them all project-managers.
    Like thats better than having them coding.

    Yeah, but I couldn't hold myself back from the dig.

    Actually, since no matter what the chosen process is or how tasks are broken up every major project I've been on has been time blocked:

    1) Management decides the new system should be finished by date X.
    2) The analysts and project manager divide the amount of tasks by the number of iterations available before date X.
    3) For each iteration-task-set you divide it evenly amongst your available developers.
    4) You ask your developers for an estimation on their tasks for each iteration.
    5) They respond by taking the number of assigned tasks, divided by the hours available in the iteration.
    6) Some magic happens (scope reduction, overtime, bring in experts to clean up, implement tasks with TODO: statements)
    7) The project finishes on date X.

    I've developed this project management process on a single MS excel sheet. I'm making it available for a cost of $1000 per seat with an annual $10K maintenance charge. Of course I can offer consulting services to customize it to your corporation at a $300/hour bill rate. Do you like curly fonts?
  8. George, your posts are superb! You just can't beat good commentary mixed with a healthy helping of cynicism.
  9. I am surprised to see that such a trivial matter is put up for discussion.Sad

    It is purely because the matter is seen as 'trivial' that many people fall into to the trap of paying it no attention.

    The phrase "Look after the pennies and the pounds look after themselves" comes to mind.


    Bob

    If you didn't learn anything today - you weren't paying attention.!
  10. sure[ Go to top ]

    The problem is that good code doesn't actually perform much better than bad code in the market. Especially in web development, people get away with some pretty bad code. Basically all the php stuff is absolute crap put together mostly by junior software engineers (in many cases without proper training). Maintaining php code is a nightmare. Still, it's a popular implementation technique. Apparently nobody cares that the code is crappy.

    There is no short term economical incentive to write good code. There's plenty of long term incentive but essentially all project based development ignores long term interest unless it is a specified project goal. Code quality rarely features in project goals. Other quality attributes do.

    Code quality is measurable and practices like code reviews (automated and manual) are a good way to guarantee it. If code quality is important in your project, put the practices in place to make sure that you deliver the required level of quality. If you don't do that, you can be sure quality will suffer.
  11. Software tends to drift toward increasing complexity without need of anyone's effort, though the efforts of inexperienced programmers and egotistic "software architects" (not as far apart in skill as their job titles suggest) can certainly bring about greater complexity more quickly.

    Simplicity is born from discipline, skill and experience: merciless refactoring, letting go of pet ideas, sharpening your Occam's Razor and slicing out objects that don't need to be there.
  12. Here, here[ Go to top ]

    If by "write code for people" he means naming variables and methods with informative names and commenting code well I couldn't agree more.

    I especially agree with doing things right and clearly the first time. I can't count the number of times I've seen multiple code blocks that do the same thing because each sucessive author fails to understand that their problem is already solved in the codebase.
  13. Heh. Pretty sour comments here.

    Why don't we - the developers - start with selecting tools and frameworks that will improve not only the quality of our products, but also in the longer term hopefully will teach the juniors how to code properly and have fun in the process of learning that.

    Why don't we *stop* selecting tools and frameworks on the merrits of quasi logical 'management sound' arguments like waving with a couple of Dice/ Monsterboard figures.

    Why don't we try to move back to proper programming again instead of focusing on code monkey style drag 'n drop tools and procedural xml centric 'stateless' frameworks.

    You are part of that corporate structure, and you can probably change more than you would think when you get off your passive ass ;) Just blaming your fellow coders and managers will not make them better nor help your organization.
  14. You are part of that corporate structure, and you can probably change more than you would think when you get off your passive ass ;) Just blaming your fellow coders and managers will not make them better nor help your organization.

    hallelujah! :)
  15. Half serious[ Go to top ]

    Heh. Pretty sour comments here...You are part of that corporate structure, and you can probably change more than you would think when you get off your passive ass ;) Just blaming your fellow coders and managers will not make them better nor help your organization.

    Hopefully, not too sour - just having some fun writing today.

    I am and am not part of the corporate structure - I'm a dreaded know-it-all consultant. Of course the better I get the more I know what I don't know, you know? I'm not saying we shouldn't try to elevate the skills of those around us. I'm just saying that for the foreseeable future much of my job at any corporate client is deciding how to best divvy up work amongst a set of developers with limited skills and experience. Out of that set only 5-10% are interested in really getting any better. I don't worry about insulting the other 90% here since they'd never come to this site or any other like it.

    While I was half joking in my posts - I was also half serious. I'd say most of the developers I meet are just adequate. They can implement methods and work the IDE but really have no idea about what is going on under the covers. This isn't whining as much as really asking what is the best way to utilize this kind of team. They will put out crap code, that is an undeniable fact. The question is how do you best isolate that to the less risky areas of a system? Can technology help here? Is there a way to structure a framework to make adequate good enough most of the time?
  16. Half serious[ Go to top ]

    The question is how do you best isolate that to the less risky areas of a system? Can technology help here? Is there a way to structure a framework to make adequate good enough most of the time?

    George, well said.
    Frankly, I double any Framework or Technology can help with bad codes.
    I would think a sense of personal discipline and religious refactoring can only save us all from back code situation.

    Similar parallel can be drawn from the medicial world where the specially doctor can do so much to help with your help, but it is the patient's personal discipline of refraining from bad habits (bad coding practises) and do much more exercise (refactoring).
  17. Half serious[ Go to top ]

    George, well said.Frankly, I double any Framework or Technology can help with bad codes.I would think a sense of personal discipline and religious refactoring can only save us all from back code situation.Similar parallel can be drawn from the medicial world where the specially doctor can do so much to help with your help, but it is the patient's personal discipline of refraining from bad habits (bad coding practises) and do much more exercise (refactoring).

    Agreed, frameworks and tools won't save from from everything. They can however make a big difference. I'm sure there is a big quality difference on average between code that is written in PHP and Java for instance. For a large part just because of the languages themselves. I think the same applies for API's and frameworks.
  18. Half serious[ Go to top ]

    Agreed, frameworks and tools won't save from from everything. They can however make a big difference. I'm sure there is a big quality difference on average between code that is written in PHP and Java for instance. For a large part just because of the languages themselves. I think the same applies for API's and frameworks.
    I agree with Eelco here, with a (web) framework you often at least know what the module and component boundaries are. It's easy to compartmentalize and isolate out bad elements. Also, the structure that a framework usually imposes makes people think about certain issues sooner than later, which incidentally leads to better quality code.
  19. Half serious[ Go to top ]

    Sure, nearly everything in our work environment acts as a +- influence on the end product, the code. The quality and attitude of the people (developers, tech management and on up the ladder). The tools we use - their suitability to the domain within which we work, and to the people using them.

    Even in an environment where the people "on up the ladder" have no appreciation for what it takes to build maintainable software, there's a lot of things a development team can do to improve the situation. Very often, these people don't care what tools/platforms we use. They're totally driven by results.

    On the last project I worked on, we had a "Chief Architect" that didn't know his ass from his elbow when it came to implementations details. Not only did he not know, he didn't care - "that's only detail"! His power tools were Visio and PowerPoint. So, as far as how we went about implementing the solution ("the details"), he didn't feel it was all that important and so didn't care. Therefore, we had a lot of control over how we did things. Of course this sort of situation would more often lead to disaster than success. Luckily for this guy, he had people around him that did care about the details, and did want to build a solution that was going to be fit to evolve through more than 2 releases before being canned.
  20. Half serious[ Go to top ]

    While I was half joking in my posts - I was also half serious. I'd say most of the developers I meet are just adequate. They can implement methods and work the IDE but really have no idea about what is going on under the covers. This isn't whining as much as really asking what is the best way to utilize this kind of team. They will put out crap code, that is an undeniable fact. The question is how do you best isolate that to the less risky areas of a system? Can technology help here? Is there a way to structure a framework to make adequate good enough most of the time?

    I know it's not a silver bullet, but I do think TDD can help in improving the quality of the code being tested. When I used it, I found it made me view my code from the outside, and as a result I tended to be more careful about what was on the inside. It's a kind of 'holistic' thing.

    It requires a different kind of discipline of course (getting coders to do test cases) but I think it's easier to enforce than just 'code better, you monkeys!'.

    Regards
    Kit
  21. Half serious[ Go to top ]

    but I think it's easier to enforce than just 'code better, you monkeys!'.

    That should have been: "code better, you monkeys, OR YOU'LL GET THE BOOT!". hehehe... "I'll ban you from the smoke-room" should also work in most cases.
  22. The question is how do you best isolate that to the less risky areas of a system? Can technology help here? Is there a way to structure a framework to make adequate good enough most of the time?

    First reaction: remember that this is what J2EE set about to solve for it's domain? I dug back into the J2EE 1.2 documentation (at http://java.sun.com/j2ee/sdk_1.2.1/techdocs/guides/j2ee-overview/Introduction.fm.html#7384) to find these (now almost hilarious) statements:

    --
    [..] it was difficult to hire and train an experienced development staff.

    The developer can rely on the platform to provide the solutions for the hard systems-level problems of developing a middle-tier service.

    [..] minimizes the cost of developer training [..]

    The J2EE application model is a major step forward in simplifying and expediting application development, by minimizing the complexity of building multi-tier applications.
    --

    Well, we now know that J2EE didn't deliver on that promise, but i'd argue that with Java EE 5 writing good code is easier and more painless than ever before (in that domain). So yes, technology/frameworks *can* help.

    Second reaction: isn't it part of the role of an architect/lead developer to nail down sufficiently the technological skeleton (aka architecture) of an application in an early project phase (and iteratively whenever it is needed later), so that less experienced developers then have clear guidance (also through code!) on how to write their contributing code?! Isn't it also part of the role of a technical project manager to try and ensure that people with the more advanced skills work on the more sensitive parts of the software?! And finally: isn't pair-development an excellent technique to ensure that code quality remains high and less skilled team members become gradually better?!

      cheers,
      gerald

    http://www.gerald-loeffler.net
  23. Interesting - funny that J2EE was supposed to be the solution. Actually, we shouldn't say that it failed. I can write an n-tier application a heck of a lot easier in Java than if I tried in any pre-Java language.

    I'm sure it can be done but servlets and their bretheren did move things forward.

    Every time technology makes an advance expectations go up. J2EE did provide an easier solution to the kinds of applications we were writing in the early 90's. Frameworks like Struts made the now-trivial websites we were creating a bit easier. Soon we'll be expecting our developer base to be handling grid computing, advanced web interfaces, etc.

    Good points in all on your post.
  24. My comment is that it seems Hohpe recognizes the work done by Martin Fowler and those before him presented in Fowlers' Refactoring book.
  25. I've found that in my experience version 1 of an application often has mostly very sound code and just a few "hurry-up" hacks/kluges that were required to meet reasonable deadlines. I consider myself an excellent programmer, but am forced nevertheless to cut corners due to realistic business pressures.

    What I will do, however, is clearly comment any such things as hacks/kluges which must be cleaned up. To prevent your app from turning to mushy pasta, you must then have the descipline to go back and refactor/recode to eliminate these transgressions. As a development manager, I have often encouraged my team to pad their estimates of subsequent tasks so that they actually have the time to do this. Properly maintaining an application over the long-term will ALWAYS require the discipline to significantly refactor older code and components--not just to improve what you didn't have time for, but because important initial assumptions have simply changed due to changes in either the business drivers or broader technology infrastructure.

    To properly maintain and carry forward any application with quality requires tremendous discipline (there's that word a THIRD time), and going back and fixing things isn't nearly as fun as building new code. The alternative, however, is rising maintenance costs, longer testing cycles, slower adaptation to business requirements, and angry business sponsors who cannot fathom why such smart people can't get things done.

    When you get down to it, only a very capable development manager has the skills to both convince higher-ups to allot time for refactoring and improving older code AND motivate developers to actually spend time on it. Even with such skills, the manager needs a corporate culture that values quality and is able to see past the next quarterly results report. Such environments are becoming harder and harder to find.

    Gideon
    GemFire-The Enterprise Data Fabric
    http://www.gemstone.com
  26. Good programmers go on...[ Go to top ]

    the problem seems to be that the people who write code write it to the best of their ability. Often this introduces concepts and constructs that the people who come to support the code do not understand.

    so... code should be written to the ability of the support people?
  27. Good programmers go on...[ Go to top ]

    the problem seems to be that the people who write code write it to the best of their ability. Often this introduces concepts and constructs that the people who come to support the code do not understand.so... code should be written to the ability of the support people?

    +1

    I think a lot of really good developers don't realize that their elegant solution is a piece of black magic to someone with lesser skills. It's all great as long as the magic works and requirements changes don't touch it, but once it needs to be changed...

    My opinion is that whoever develops the code should maintain it, or at least work for the same person as the one maintaining it. When presented with an idea for a new application, I often ask "Who do you envision maintaining this application? and "What do you expect the annual maintenance budget to be?" before I ask about initial funding and schedule contstraints. I find it's a good way to kill doomed projects before they start, because people want magical perpetual motion applications that "just work," but of course all they don't want to pay or wait for it.
  28. Good programmers go on...[ Go to top ]

    When presented with an idea for a new application, I often ask "Who do you envision maintaining this application? and "What do you expect the annual maintenance budget to be?" before I ask about initial funding and schedule contstraints. I find it's a good way to kill doomed projects before they start, because people want magical perpetual motion applications that "just work," but of course all they don't want to pay or wait for it.

    I like that approach. It always pays to put everything in terms of time and dollars when talking to managers.

    I doubt though that whoever writes the code will be the maintainer in many environments. Many times the companies developers are responsible for maintenance so they bring in consultants for the new work. Then the consultants go away.

    Maybe another thing to ask at the beginning of a project is "what existing project can we retire to make room for this one"?
  29. Good programmers go on...[ Go to top ]

    I doubt though that whoever writes the code will be the maintainer in many environments. Many times the companies developers are responsible for maintenance so they bring in consultants for the new work. Then the consultants go away.

    I have no doubt that this is the case. I fight this tooth-and-nail when upper management "suggests" that I use consultants for a project. IMHO consultants should do just that - consult.

    This is one case where I prefer outsourcing. If an outside company is going to build a system, then there should be a complete support contract for the system - a fixed price contract for bugs or cases where the system fail to meet the spec. Of course in practice this demand seems to be completely delusional, but maybe someday, somewhere...
  30. Good programmers go on...[ Go to top ]

    +1I think a lot of really good developers don't realize that their elegant solution is a piece of black magic to someone with lesser skills.

    I think that if it was *really* elegant, it probably would have been comprehensive, even to those with lesser skills. Complicated, hard to follow code usually does not equal good/ elegant code - unless it is some highly optimized wizardry in which case it might be good but probably still not elegant.

    Furthermore, the lesser skilled have to learn it from somewhere. Looking at some decent code just might get them some good ideas.
  31. +1I think a lot of really good developers don't realize that their elegant solution is a piece of black magic to someone with lesser skills.
    I think that if it was *really* elegant, it probably would have been comprehensive, even to those with lesser skills. Complicated, hard to follow code usually does not equal good/ elegant code - unless it is some highly optimized wizardry in which case it might be good but probably still not elegant.Furthermore, the lesser skilled have to learn it from somewhere. Looking at some decent code just might get them some good ideas.

    With regards to this issue, there is absolutely no better way to help those that follow you than to properly comment your code. When I write code, even a non-technical business manager can understand what it's doing because the comments read like a narrative. When using any advanced techniques that a more junior developer may need to learn, explain the advantages and rationale in your comments! It takes a little more time, but (at least for me) but detailed commenting actually helps me to think through my logic more carefully and catch errors earlier.

    Doing this requires, dare I say it again . . . Discipline. If you are a good coder, show your pride in your work by properly explaining it those that follow you.

    Cheers,

    Gideon
    GemFire--The Enterprise Data Fabric
    http://www.gemstone.com
  32. Comments[ Go to top ]

    +1I think a lot of really good developers don't realize that their elegant solution is a piece of black magic to someone with lesser skills.
    I think that if it was *really* elegant, it probably would have been comprehensive, even to those with lesser skills. Complicated, hard to follow code usually does not equal good/ elegant code - unless it is some highly optimized wizardry in which case it might be good but probably still not elegant.Furthermore, the lesser skilled have to learn it from somewhere. Looking at some decent code just might get them some good ideas.
    With regards to this issue, there is absolutely no better way to help those that follow you than to properly comment your code. When I write code, even a non-technical business manager can understand what it's doing because the comments read like a narrative. When using any advanced techniques that a more junior developer may need to learn, explain the advantages and rationale in your comments! It takes a little more time, but (at least for me) but detailed commenting actually helps me to think through my logic more carefully and catch errors earlier. Doing this requires, dare I say it again . . . Discipline. If you are a good coder, show your pride in your work by properly explaining it those that follow you.Cheers, GideonGemFire--The Enterprise Data Fabrichttp://www.gemstone.com

    Every manager I know loves the sound of "apply comments liberally to your code."

    However, quoting Martin Fowler:
       If you need a comment to explain what a block of code does, try Extract Method (110). If the method is already extracted but you still need a comment to explain what it does, use Rename Method (273). If you need to state some rules about the required state of the system, use Introduce Assertion (267).

       When you feel the need to write a comment, first try to refactor the code so that any comment becomes superfluous.
  33. Comments[ Go to top ]

    However, quoting Martin Fowler:
       If you need a comment to explain what a block of code does, try Extract Method (110). If the method is already extracted but you still need a comment to explain what it does, use Rename Method (273). If you need to state some rules about the required state of the system, use Introduce Assertion (267).   When you feel the need to write a comment, first try to refactor the code so that any comment becomes superfluous.

    Agreed mostly (of course, how could one not agree with MF) but... one thing that you never get from variable and method names is just some explaination why the author made a certain decission and what his/ her intention was. And furthermore, comments - preferably JavaDoc - are good for defining the contract if that can't be enforced in just the code. It can explain how it fits in a larger whole, etc. So as usual, the world is grey.
  34. Good programmers go on...[ Go to top ]

    I think that if it was *really* elegant, it probably would have been comprehensive, even to those with lesser skills. Complicated, hard to follow code usually does not equal good/ elegant code - unless it is some highly optimized wizardry in which case it might be good but probably still not elegant.

    Many developers have no understanding of concerns like concurrency and transactions. I don't think you can learn these simply by staring at code. At least with concurrency, I think some people can grok it and some can't, no matter how hard they try.

    Start throwing in concepts like metaprogramming (especially in dynamic languages), dependency injection, aspect-oritented programing, etc - all techniques that can produce elegant code, but if a programmer doesn't understand the fundamentals of them they will appear to be witchcraft.
  35. Good programmers go on...[ Go to top ]

    Start throwing in concepts like metaprogramming (especially in dynamic languages), dependency injection, aspect-oritented programing, etc - all techniques that can produce elegant code, but if a programmer doesn't understand the fundamentals of them they will appear to be witchcraft.

    But that's exactly my point: I don't think throwing in all those things make elegant code at all!