Discussions

News: TSS Asks: Getting back your investment

  1. TSS Asks: Getting back your investment (19 messages)

    Very recently, I had the privilege to audit a very large J2EE portal implementation and also got a sneak preview of some J2EE banking product source code. To my surprise, I found that both these lacked even a very basic commitment to standards of good coding practices.

    I believe most of the enterprise takes pride in the technology that they use but fails to make sure that the implementation (coding and other standards) is of top quality. There can be justifications for this as nowadays we work on tighter deadlines, resulting in trying to finish the projects by any means, but...

    For example, in one of the projects, I found that in every JSP, there was a single try/catch block enclosing even the <HTML></HTML> blocks. The Enterprise Java community has come a long way and I believe these are all practices that can give its competitor an edge while undergoing quality assurance tests.

    Just a set of questions to ponder:

    How can I quantify the return on investment from a J2EE project? When we justify the investment on a J2EE project, should we take the quality of the code into consideration as well? If I make a huge investment, should I be delivered code that's of top quality since I have paid the developers a good hourly rate?

    Threaded Messages (19)

  2. In most businesses software is a tool to help business processes to move along. It’s ROI depends mostly on how well that software meets business requirements and quality is secondary. For instance, an oil company, in today’s world would make money no matter what. If software for that company helps them in their line of business, then it’s most likely to have a very ROI, almost regardless of quality. Low quality often simply means that maintenance costs are high (hard to add functionality, performance is slow requiring more powerful hardware and so on). Sometimes that can kill a business, but often it does not. Businesses (upper management, really) rightfully care about things that make big difference and do not have for the rest. In my view software quality (unfortunately) often falls in the “rest” category.

    Lower quality expenses are very hard to condense and separate from overall maintenance cost, especially if you consider living and evolving system. As such the only way to minimize them is to have technically competent stuff to oversee development process. Something can be done by analyzing existing code and improving processes along the way. But as always the rewards are greater if good quality is enforced from the beginning

    I agree with you that in many companies software quality is lacking. Lack of environment that promotes good quality and also difficulty in measuring quality (where does quality ends and coding style begins?) are common causes for this.

    I also think that you should definitely ask for the best possible quality from your developers (why not?), especially if their rate is good. But the only way to get that quality is to enforce proper development processes during design and development. If left alone, luck of common design approaches and mediocre developers would bring the quality down.

    Software quality is important concept. While it might not always make a big and direct impact on the bottom line, it does help to retain good developers and definitely (even if little) helps in the long run.
  3. I would agree with the above poster that it is the business bottom line that counts:
    Does the software contribute to lowering costs or increasing revenue?
    That's what counts as far as the business is concerned. How you would quantify this depends on what the particular system does. For a call-center application it may be things such as average time per customer call (change in time), average calls taken per hour, average problems resolved etc.
    The key is finding the correct quantifyable "X per Y" ratio to measure, and quantify it into money, which can then be used determine the ROI.

    As far as quality goes, I would partially have to disagree with the former person in his assertion that quality is secondary:
    Maintenance costs during a systems lifetime are considerably higher than development costs.
    A system that is better quality should definitely be easier (read: cheaper) to maintain, and easier to change and extend, and will most likely also have a longer life-span before it needs to be replaced.
    Being able to make some qualified measurements and/or assumptions around areas like this will likely help you take quality into the equation when determining an approximate ROI (what does it cost per month to keep the system running? What is the effort and complexity in changing or adding functionality? etc).
  4. What affects the maintenance cost of large systems is how well programmers understand them. Coding conventions, design patterns, best practices and good help improve code comprehension, but in my opinion the best technique is probably code reviews (which are pretty expensive).

    Of course if I understand your comment, what you want to know is how to quantify quality in order to find an equilibrium between dev and maintenance costs. There is no metric that you can apply on the codebase able to tell you (it will give you hints) if the software is of good quality. From the point of view of someone on the outside, the best you can do is observe how the codebase changes. If a "small" change in requirements forces someone to change a sizeable part of your codebase, then you can imagine it that there is a problem (but still not quantifiable).

    Good Luck
  5. If a "small" change in requirements forces someone to change a sizeable part of your codebase, then you can imagine it that there is a problem (but still not quantifiable).

    You assume the application is architected in horizontal layers rather than vertical functions. If an application is coded in a manner so that each feature exists as a silo, with common code simply cut & pasted between silos (or entirely reimplemented), small changes in requirements will result in small changes to code so long as they don't cut across features.
  6. Problematic[ Go to top ]

    You assume the application is architected in horizontal layers rather than vertical functions. If an application is coded in a manner so that each feature exists as a silo, with common code simply cut &amp; pasted between silos (or entirely reimplemented), small changes in requirements will result in small changes to code so long as they don't cut across features.

    Of course when (not if) that happens, the changes to all that cut-and-pasted code are very expensive indeed. This is well understood.

    I think there are as many problems raised with 'good coding standards' as there are problems solved. Many, I would guess most, experienced developers find it hard to distinguish between 'good standard' and 'what I personally do'. In the example given by the author, for instance, I am not particularly horrified by a catch-all try/catch block. We don't do this, but the world will not end if we did.

    As for quantifying the value of code quality ... of course you CAN do this. NASA has been doing it for years, for instance. However, it is very expensive relative to current practice in the United States. NASA has a big budget.

    I think, too, that an argument can be made that points out that McDonald's make a lot more money than, say, Henri's in Paris, although Henri makes the superior salad.

    Not trying to be cynical here - it's just that I think it is not always as important to worry about high quality code as it is to worry about getting a product out the door. Sometimes that high quality IS more important; in my view that is a business decision rather than a technology decision. In my excperience, that is a unusual situation - I might even say very unusual. Yet many times these discussions are dominated by developers with a technologically-oriented point of view.

    One thing that is interesting to me is that accepting the reality of low quality code may actually be a business virtue from the developer's point of view. After all, you can be pretty sure that more work will be available later. Again, without being cynical, I can only point out that many products are built that way outside the software world. I'm not sure it makes sense to strive for standards exceeding the practices of the business cultures in which we are embedded. There is a real dollar value in having to do it over, as many long-time developers can attest.
  7. Problematic[ Go to top ]

    As for quantifying the value of code quality ... of course you CAN do this. NASA has been doing it for years, for instance. However, it is very expensive relative to current practice in the United States. NASA has a big budget.


    True, NASA has metrics on process, resources and software (it also uses formal verification). My comment (unclear, sorry) was quality is however not measured directly from the code. It is estimated from different sources.

    From my personal experience, good software needs to be rewritten a few times before it is truly of good quality. True quality requirements will appear over time.
  8. Problematic[ Go to top ]

    As for quantifying the value of code quality ... of course you CAN do this. NASA has been doing it for years, for instance. However, it is very expensive relative to current practice in the United States. NASA has a big budget.


    True, NASA has metrics on process, resources and software (it also uses formal verification). My comment (unclear, sorry) was quality is however not measured ..

    .. in feet or meters?

    (A subtle reminder that there is more than one kind of error. ;-)

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Shared Memory for Java
  9. Doesn't this always come back to the old adage "You can have it fast, cheap and good but you only get to choose 2"

    In my experience, more often than not unrealistic deadlines or weak requirements are the reason for poor code quality.
  10. I think that, to unrealistic deadlines and weak requirements, we could add the short-sighted greedy way in which some management people choose developers based only on their low rates. And I am not saying that low-rate developers are necessarily poor coders, but here in Mexico, more often than not, they are Junior Developers still learning by trial and error. This frequently results in poor quality software artifacts.


    Carlos
  11. In my experience, more often than not unrealistic deadlines or weak requirements are the reason for poor code quality.

    Weak requirements come from weak objectives. The first question that should be asked on a project is the "R" in ROI. How/where do you expect to get a return on your investment? How big? By cutting the effort required for Bob to produce TPS reports in half? Does Bob agree? How much time does Bob spend producing TPS reports? Do we really need TPS reports, or are we just trying to produce junk faster?

    The list of questions goes on and on, and most times people have no clue. They think a webapp that can be developed by a intern in 2.5 minutes using RoR will cure world hunger, stop the green house effect, ensure world peace, and earn everyone a $10 million dollar bonus. (or a $10 gift certificate if you actually worked on the project)
  12. ROFL[ Go to top ]

    They think a webapp that can be developed by a intern in 2.5 minutes using RoR will cure world hunger, stop the green house effect, ensure world peace, and earn everyone a $10 million dollar bonus. (or a $10 gift certificate if you actually worked on the project)

    Becvause of the Agileness of the crosscutting concerns in RoRs inversion of control, all this is possible ! And it will be lightweight, yet portable !
  13. One other thing ...[ Go to top ]

    How many of you can tell me the ROI of the last project he worked on ? This is a dollar figure, mind you.

    I've met a LOT of consultants who talk a LOT about ROI, but I have yet to meet one who can give me that figure. Some are able to make up something quickly, but the hesitation is such a special thing to see that it spoils the effect ;-)

    I know some of you can. I'm just making a point of sorts. No offence intended, as I certainly cannot tell yuou this figure.

    'Course I don't pretend I care about it, either. People that pay millions of dollars for Super Bowl ads don't deserve ROI ;-)
  14. ...To my surprise, I found that both these lacked even a very basic commitment to standards of good coding practices...

    You were surprised? seriously? I'd be knocked on my ass if I reviewed a corporate code base and found even a marginal commitment to quality.

    Corporate Code smells:
    1) WSAD - There is a reason it isn't called WHAPPY
    2) Only javadoc is the eclipse message telling you how to change your default javadoc templates
    3) No interfaces at all or an interface for every class
    4) junit.jar exists in the lib directory but no tests to be found
      4a) I got this unit test that calls the production database
    5) optimized imports? code formatting? we don't have time in the project plan for that
    6) Sure we use Spring, but we wrap it with our own classes so we can switch it out later
      6a) We've cached the bean instance returned by Spring to speed things up
    7) We added hibernate because we knew we were going to hit the database
    8) Synchronization? Threads? the container takes care of that
    9) Guys, look at this framework I cranked out last night!
    10) With annotations I was able to expose all my classes as web services, you know, for reuse!

    I only wish I was joking.

    I don't think maintenance is an issue if you have to rewrite each system every 3-5 years.
  15. The whole point is not about junior developer or senior developer. Many a times I have seen senior developer writing poor code and junior developer writing good code. Here good code means following good coding practices. Its all about what you believe. Some people don't give a damn to good coding practice and try to force complicated design patterns even though there is no need and can achieved by simple logic. Ultimate aim to deliver a good quality product which does certain task and not how skillful you are in implementing a particular design pattern or something.
  16. Yeah, a person's title has little to do with anything. Even their experience: Many corporate developers with years of experience really only have years of experience doing the same thing. Same goes for consultants who stay at clients too long or keep getting the same types of gigs.
  17. LOL[ Go to top ]

    ...To my surprise, I found that both these lacked even a very basic commitment to standards of good coding practices...
    You were surprised? seriously? I'd be knocked on my ass if I reviewed a corporate code base and found even a marginal commitment to quality.Corporate Code smells:1) WSAD - There is a reason it isn't called WHAPPY2) Only javadoc is the eclipse message telling you how to change your default javadoc templates3) No interfaces at all or an interface for every class4) junit.jar exists in the lib directory but no tests to be found &nbsp;&nbsp;4a) I got this unit test that calls the production database5) optimized imports? code formatting? we don't have time in the project plan for that6) Sure we use Spring, but we wrap it with our own classes so we can switch it out later&nbsp;&nbsp;6a) We've cached the bean instance returned by Spring to speed things up 7) We added hibernate because we knew we were going to hit the database8) Synchronization? Threads? the container takes care of that9) Guys, look at this framework I cranked out last night!10) With annotations I was able to expose all my classes as web services, you know, for reuse! I only wish I was joking.I don't think maintenance is an issue if you have to rewrite each system every 3-5 years.

    Stop ! YOu're killing me !

    And look at the ad athe bottom of this page :

    "JSP Programmers $10/hour"

    Sometimes you get what you pay for. US corporate metality is interesting in this regard.
  18. 1) WSAD - There is a reason it isn't called WHAPPY

    LOL ooh... too true...
  19. Rewrites as maintenance[ Go to top ]

    ...I don't think maintenance is an issue if you have to rewrite each system every 3-5 years.

    Yes, I would have to agree that it is difficult to concentrate on the finer points of good coding practices when a lot of the code will be redone on the next pass using a different technology or a "refined" understanding of the requirements. Those recoding efforts can get expensive though if the guilty aren't around to explain what the stuff does, as, of course, there certainly wouldn't be time for any documentation to be produced.

    I had some success on a project when I had the (mostly contract) developers agree to some basic principles that allowed the product to survive through numerous changes as the kimono slowly opened to reveal the real requirements. One such practice that proved invaluable was the use of a consistent error logging mechanism in both the client and server code that at least allowed us to track down the inevitable errors from requirements problems and too-short deadlines.

    I have found that even in busy development environments there are lulls while waiting for clarifications, funding, whatever, that can be used to simplify things like agreeing on standards and building tools to assist. We had an IDE plugin that automatically created the previously mentioned logging code, for example. Such lulls can also be used to clean up the hastily written stuff. We insisted that the development team be allowed to contribute tasks to upcoming releases so that we could fix the things that we knew were going to come back to bite us. I would represent the team during the prioritization sessions to explain to the business why it really was in their best interest to allow us to do the remedial work.

    I think that any real-world development project is going to involve compromise. You need to find the best balance to achieve the results, which is why, I think, that we don't hear a lot of success stories from software metrics.
  20. ...that allowed the product to survive through numerous changes as the kimono slowly opened to reveal the real requirements...
    This is a little suggestive and poetic for something as dull as requirements. Don't know if I should yawn or feel tingly.
    We insisted that the development team be allowed to contribute tasks to upcoming releases so that we could fix the things that we knew were going to come back to bite us. I would represent the team during the prioritization sessions to explain to the business why it really was in their best interest to allow us to do the remedial work.

    This sounds sensible. If you are any kind of a lead on a project it is your responsibility to fight for bubbles of time to fix shortcomings. Smarter, experienced project managers will have expected this and allow you to add change requests. Otherwise, you have to sneak the fixes in when you can. I have no problem overestimating a defect fix or new feature on a project if I know I need to divert a few more hours to some house cleaning. I'd rather work with the PM but at times you got to do what you got to do.