May 18, 2008 at 7:36 pm
Software Quality and consistency is notoriously hard to measure.
An Elegant solution has risks that a solution that follows the path of least surprises does not.
It is worth distinguishing between consistency of product (result) and consistency of method.
And then again between consistency in approach across the industry v consistency with product / code base being maintained.
It would be also worth distinguishing between visible goals (pragmatic professionalism) and maintainability goals (Ideal professionalism).
There is no golden hammer to define how much effort should be spent for quality or consistency on any individual systems architecture and life cycle.
If people are confused enough about consistency or quality to actually argue for boiler plate variable definitions or Hungarian Camel notation, then I think they are well short of a concept of readability. Let alone those poor souls that break out logic into separate named blocks before there is any need to reuse them. Or even still that time Honoured Cobol practice of moving everything in locally defined working storage references in a language that holds symbolic references rather than copy by value variables.
While it is not always possible or practical I consider that consistency of method with current industry practice to be an ideal as important as consistency with the historical standards of a code base.
An Easy one would be Single point of Truth which is an ideal to limit the amount of duplication of a logical assertion in a code base. Lets not redefine an identically structure / object / interface for each code block please.
About the best we can hope for is to not repeat our poor judgements of suitability and be open to identified
areas where we can improve any facet of our coding whether for maintenance, time to market or some form of standardisation.
May 19, 2008 at 6:59 am
DAvid (5/18/2008)
Software Quality and consistency is notoriously hard to measure.Let alone those poor souls that break out logic into separate named blocks before there is any need to reuse them.
An EXCELLENT example of how you can get into trouble by voting for consistency.
Breaking a program into blocks can have enormous readability benefits by thinking hierarchically. Being able to see an overview of the logic flow of a program all on one page can guide you to the pieces(s) of code that need looking at sometimes in seconds rather than spending hours wading through pages and pages of in line code trying to work out which IF from pages back connects to the END you just came across.
But by the same token, a repetitive piece of code doing a lot of similar things has absolutely no value being broken up unless any of the pieces contain complex code.
A quality programmer who takes pride in their work can, and often will, use both techniques depending on context; keeping stuff in line where it just flows from end to end and breaking code out when it creates a nice summary overview of the logic.
May 19, 2008 at 7:19 am
CypherOz (5/18/2008)
In the context of commercial code... Quality is consistency.If code can be written by developer A and in 6 months developer B can pick it up and feel at home with it you have quality code.
Super optimized, hard to read or understand code is bad - no matter how 'kewl' it is.
Remember KISS!
What if developer B comes along and sees something they're NOT used to; but after 20 minutes fathoming out how it works takes 3 hours less making the change, 8 hours less testing it and starts using the same techniques in all his subsequent code; haven't you then created MORE quality? Haven't you created a chain reaction that's going to improve the quality of code throughout your installation? Was saving that 20 minutes for a learning curve really good value for money?
I prefer the mantra of one of my better managers: "If you're going to do something out of the ordinary then document it, in the code, very thoroughly and be prepared to justify it in the code walkthrough. If enough people hate it you'll have to change it".
May 19, 2008 at 6:49 pm
ntaylor (5/19/2008)
I prefer the mantra of one of my better managers: "If you're going to do something out of the ordinary then document it, in the code, very thoroughly and be prepared to justify it in the code walkthrough. If enough people hate it you'll have to change it".
Heh... I agree... except my mantra is "document everything in the code".
--Jeff Moden
Change is inevitable... Change for the better is not.
May 19, 2008 at 9:41 pm
ntaylor (5/19/2008)
What if developer B comes along and sees something they're NOT used to; but after 20 minutes fathoming out how it works takes 3 hours less making the change, 8 hours less testing it and starts using the same techniques in all his subsequent code; haven't you then created MORE quality? Haven't you created a chain reaction that's going to improve the quality of code throughout your installation? Was saving that 20 minutes for a learning curve really good value for money?
I prefer the mantra of one of my better managers: "If you're going to do something out of the ordinary then document it, in the code, very thoroughly and be prepared to justify it in the code walkthrough. If enough people hate it you'll have to change it".
Not disagreeing about learning. BUT in general terms the simpler the better. Of course new techniques can be introduced. If a developer has a better way of doing it they can present that to our team (and they do). If it makes sense we take it up into our standards.
A scientific theory should be as simple as possible, but no simpler. -- Albert Einstein Applies to software just as well.
May 19, 2008 at 9:48 pm
Yes.Consistency IS quality.
May 19, 2008 at 9:48 pm
ntaylor (5/16/2008)
I'd follow a bit on what Jamie said: consistency tends to breed quality.I disagree. Consistency is the long term enemy of quality. Consistency breeds stagnation and prevents the adoption of quality improvements.
[snip]
Case in point - internal Cobol sorts.
[snip]
Y2K
Depends on the team environment. If the SDLC etc provides for, and encourages, improvement then there is not a problem. As new ideas and technology become available they must be evaluated and incorporated.
I must have been lucky over the last 30+ years in working with innovative teams. A static set of standards is a bad idea. Controlled improvement of standards is good - especially when rewarded.
May 20, 2008 at 6:16 pm
Consistancy aids in the quality of readability. But it is not all qualities.
There is a point when any template for a solution is used commonly enough that it should become a generic re-used component.
Limiting human error and centralizing logic (single point of truth). This is not consistent with the existing template model.
But the problems being solved change and assuming that a preconceived standard is appropriate for all problems only demonstrates that your code is missing a quality called re-use.
Re-inventing is also an enemy of re-use (probably bigger) so a consistent recognition of similar problems as candidates for generics can improve many maintainability, constancy and efficiency qualities. (or conversely recognising problems as not fitting a pattern and putting your golden hammer away)
Some developers seem happy enough to cross over to the dark side of the force though.
Avoiding re-use as it only limits their billable hours in a contracting scenario.
Or choosing patterns based on self interest rather than appropriateness for the problem domain.
May 21, 2008 at 7:25 am
CypherOz (5/19/2008)
ntaylor (5/19/2008)
What if developer B comes along and sees something they're NOT used to; but after 20 minutes fathoming out how it works takes 3 hours less making the change, 8 hours less testing it and starts using the same techniques in all his subsequent code; haven't you then created MORE quality?
Not disagreeing about learning. BUT in general terms the simpler the better. Of course new techniques can be introduced. If a developer has a better way of doing it they can present that to our team (and they do). If it makes sense we take it up into our standards.
How do you know? How do you measure how many good ideas were rejected in error or just because of a poor presentation? How do you account for exceptions o the rule; almost every standard has an exception. Do you have any allowance built in for those situations?
Let's take the simplest and most common one of the lot: Don't Use GoTos.
In languages the don't have an "ElseIF" construct or a versatile CASE structure that allows you to put different conditions on each WHEN clause there are common types of code where a GoTo can improve readability over nesting IF statements 20 or more levels deep.
And look who ends up making those decisions. It's not the best and the brightest; they're too busy with real work. It becomes the people who WANT to do that. The people who want to see everything the same, who're afraid to try something new.
May 21, 2008 at 8:39 am
Consistency != inflexibility
If you want to try something new, then you develop a consistent way to do it, propose it to the group, explain it, debate it, etc. and make a decision.
The idea is that everyone is aware of what others are doing and they code consistently in terms of style, structure, comments, etc. That way someone can pick up code and know what's likely to be happening. That doesn't prevent mistakes, or prove quality, but it does give some stability to the system.
Evolving your rules over time is fine, you just want everyone to be aware of the changes, not each person building it their own way.
May 21, 2008 at 8:53 am
Steve Jones - Editor (5/21/2008)
Consistency != inflexibility
Hasn't != been deprecated???:D And I agree wholeheartedly, evolution is inevitable. As long as it's handled properly, it can/will be a wonderful thing!
-- You can't be late until you show up.
May 21, 2008 at 8:58 am
Consistency is my first choice and I believe consistency brings quality. You have to be consistent always. 🙂
May 21, 2008 at 9:10 am
Properly done, written enforced standards won't prevent someone from trying something new, but a process outside the standards should be approved for use. For example, we have a standard that says, "In general, the use of correlated sub-queries is discouraged because of their impact on performance." However, recognizing that there are certain high performance exceptions for them (like finding missing ranges in a sequence, for example), there's a catch all for exceptions... "Please check with the DBA's or Sr. Data Analyst for possible alternatives or concurrence for usage of non-standard code prior to submitting the code for review."
Properly done, standards/guidlines will keep people from making costly mistakes that they may not be aware of as well as enforcing some simple readability rules. Prior to our company invoking such a set of standards, along with the required code reviews, we had an average of 640 deadlocks per DAY and many of the "nightly runs" would take 8 to 40 hours to, many times, fail. After reworking much of the code to meet the standards, most nightly runs now run in 3 seconds to 30 minutes and just don't fail anymore. Research to modify code now takes 30 minutes or less instead of 2 days and that not only makes managers happy, it makes the Developers really happy because they can get more done in a shorter time... makes them look really good and they know it. Further, because they have to look at their own code a bit more to make sure it meets the standards, they are finding their mistakes and correcting them long before their code makes it to test. The amount of costly rework for such failures in test has dropped to near zero. Everybody, especially the Developers, likes that.
Further, properly written standards will also teach newbies how to write better code without someone having to "baby sit" them.
Yes, it takes a bit more time upfront and code reviews to enforce the standards can seem like a bit of a bottleneck... but the managers and our Developers recognize how much time it saves in research and rework. The DBA's love it because they don't get paged at 2 in the morning anymore... all without stifling creativety. 🙂
--Jeff Moden
Change is inevitable... Change for the better is not.
May 21, 2008 at 12:08 pm
Jeff Moden (5/21/2008)
Properly done, written enforced standards won't prevent someone from trying something new,
Again, though. How do you measure when it's being properly done? You can easily measure when new things go wrong but there is no known measure for when rejected ideas would have been better. Evidence always stacks up higher and higher against change because improvements are hard to evaluate and potential improvements rejected are impossible to evaluate.
Besides which: some of the other descriptions in your post suggest that you're really talking about quality standards and guidelines as opposed to consistency standards.
Consistency DOES = Inflexibility. Every element of flexibility is by definition a deviation from consistency and an admission that other things can be more important.
May 21, 2008 at 12:16 pm
If the SDLC etc provides for, and encourages, improvement then there is not a problem.
If the SDLC etc provides for, and encourages, improvement then you have acknowledged that quality overrides consistency.
Viewing 15 posts - 46 through 60 (of 75 total)
You must be logged in to reply to this topic. Login to reply