Weblogs Forum - What is good code?

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Weblogs Forum
What is good code?

35 replies on 3 pages. Most recent reply: Mar 30, 2005 8:09 PM by Scott Bockelman

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 35 replies on 3 pages [ 1 2 3 | » ]

Kirk Knoernschild

Posts: 46
Nickname: kirkk
Registered: Feb, 2004

What is good code? (View in Weblogs)

Posted: Feb 25, 2005 7:48 PM

Summary
Wow. A lot of debate on quality versus velocity. I'm wondering if we're all on the same page with what we mean by quality.

What exactly is quality code? The gem that got the ball rolling was Robert C. Martin's statement...

The only way to go really fast is to write the best code you can possibly write, with the best design you can possibly give it.

Ignoring speed of development for a moment, is the best code software that:

can adapt to change

performs well

is error free

is as simple as possible

does what my customer needs

At the end of the day, if I've missed the mark on any of these, I've failed.

Kart Bart

Posts: 2
Nickname: kartbart
Registered: Jan, 2004

Re: What is good code?

Posted: Feb 27, 2005 3:55 PM

<p>Ignoring speed of development for a moment, is the
<i>best code</i> software that:
<li>can adapt to change
<li>performs well
<li>is error free
<li>is as simple as possible
<li>does what my customer needs

I submit that "good quality" code is none of the above. In the software world, for some strange reason, business and market forces are always ignored and poeple tend to shoot for some utopian ideal. Let me illustrate and put forth, how I as an Architect approach software quality on my projects.

Would you consider the Lexus LS 400 a good quality car? Absolutely? Do you think it is successful? Absolutely? Well, wait, there are more Honda Civics sold than the LS 400. How is that? To define quality as a set of "illity" attributes (reliability, maintainability, readability, enhance-ability, performability, scalability, etc) without consider the business drivers behind the reason for creating the software in the first place is futile. The Lexus caters to a specific market that looks for certain attributes. Cost is not one of them. The Honda Civic caters to a different market, where cost/quality ratio is a whole lot more important.

In the same way, when you approach building software, first ask what business drivers are behind it? Does it need to be introduced quickly? Is this running a critical operation where downtime cannot be sacrificed? Is this to prove a concept and get funding for a larger venture? Each of these requires a particular set of illities to be "magnified" and some other illities to be "sacrificed." Example, a fast time to market generally means the "developmentability" of the software should be very high. Very often, this means sacrificing "maintainability", "extensibility", "performability" to some degree. The same way, a mission critical app that has stringent defect and uptime requirements needs to have high "verifiability," "testability," "reliability" and this inevitability precludes "developmentability" and low-budget.

In most software development projects, if you list of the business drivers and map them to "illities," you will find that the illities are in conflict. You then need to get the business stake holders to prioritize the business drivers to get the list of illities to focus on. One can easily create a matrix of prioritized business drivers and contributing "illities" and come up with a weighted rank for the most important one after eliminating the conflicts.

From that point on, your architecture, development plan, design and decisions should be deliberately skewed to reflect those illities. At the end of the day, you may not fit the misconceived notion of software quality - but your business stakeholders will call the software a success and it will indeed be. The beauty of this approach is not only in producing the "right stuff" but in being able to defend your decisions against those pesky people who always complain about some favorite "illity" of theirs being sacrificed. By going back all the way to the business drivers of the stakeholders, you can tell them to put up the dough or shut-up.

Randy bielby

Posts: 3
Nickname: rbielby
Registered: Oct, 2003

Re: What is good code?

Posted: Feb 27, 2005 4:01 PM

I've recently had a discussion regarding craftsmanship with some co-workers. I made a couple statements that I think reinforce the point you are making.
-Taking pride in how we create software, elegant yet functional
-High performing yet easy to maintain
-Implementing with latest technologies, but remembering the mistakes we made with older technologies
-Code is code is code, but the thought that goes into creating it, that's what really counts

So, yes I agree, at the end of the day, you have failed if you have neglected any of the points you stated

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: What is good code?

Posted: Feb 27, 2005 6:08 PM

> In most software development projects, if you list of the
> business drivers and map them to "illities," you will find
> that the illities are in conflict.

We'll also probably find that the business drivers are in conflict to some degree.

> You then need to get
> the business stake holders to prioritize the business
> drivers to get the list of illities to focus on. One can
> easily create a matrix of prioritized business drivers and
> contributing "illities" and come up with a weighted rank
> for the most important one after eliminating the
> conflicts.
>
> From that point on, your architecture, development plan,
> design and decisions should be deliberately skewed to
> reflect those illities. At the end of the day, you may not
> fit the misconceived notion of software quality - but your
> business stakeholders will call the software a success and
> it will indeed be.

Well, it will be aligned with the business drivers, whether it is a success is an entirely different matter.

In general I agree - House of Quality

Michael

Posts: 12
Nickname: target
Registered: Jan, 2005

Re: What is good code?

Posted: Feb 28, 2005 4:30 AM

>At the end of the day, if I've missed the mark on any
> of these, I've failed.

I'd better write "at the end of the release", since one working day is not enough to measure all mentioned parameters. For example, performance optimization likely will be done close to release date.

Michael
http://blog.targetprocess.com

Nicolas Nombela

Posts: 17
Nickname: nnombela
Registered: Feb, 2005

Re: What is good code?

Posted: Feb 28, 2005 7:46 AM

I almost agree, but I would say:

primary goals:

* Easy to read, understand and use
* Easy to change/modify
* Simple as posible

secondary goals:

* is fully and correctly tested
* tests what my custumer needs

Dan Perl

Posts: 28
Nickname: nanov
Registered: Sep, 2004

Re: What is good code?

Posted: Feb 28, 2005 9:58 AM

I see three categories of people who interact with the code and for whom quality has different aspects: end users, testers and developers.

Ultimately (or, as you say, at the end of day), the quality of the code lies with the quality of the product and that lies with the end users. That comes down to things like correctness, reliability, usability, performance and even "looking pretty". These quality aspects are usually more obvious although they vary from user to user and from product to product.

However, our discussions on quality code revolve mostly around the aspects that are relevant to developers and testers, as opposed to the end users. Developers and testers are users themselves, only at a different level. That is where other quality aspects come out, based on how developers and testers use the code: readability, usability, re-usability, ease of change, testability.

Now, the end-user quality is supreme. The developer/tester quality is relevant only if it adds to the end-user quality or to other values relevant to end-users (like speed of delivery, price; and BTW, there are trade-offs between these values). This happens especially if the product is developed by a large team and over a long period. If the product is developed by only one person in a few days, aspects like readability and ease of change are not very important at all. If you write SQL statements, readability is important but, in the end, performance can override readability (performance is one of the end-user quality aspects).

Those are my 2 cents on code quality. I may not give a clear answer to your questions, but I propose a different view of the list that you are suggesting (which is too flat in my opinion).

Robert C. Martin

Posts: 111
Nickname: unclebob
Registered: Apr, 2003

Re: What is good code?

Posted: Feb 28, 2005 10:02 AM

Good code is code that you are proud to release. Code that you know you have done your best on. Code that you *know* works, and that you have given the best design you can think of in the time available. This is not perfection, it is dilligence; it is professionalism.

Good code should address the following issues with roughly the following priority:

1. It should be very high in business value.
2. Test coverage should be near 100%
3. It should be simple.
4. It should have as little duplication as possible.
5. It should be expressive.

I consider these issues to be important. However, I consider the intent of the programmer to be more important. If the programmer is trying his/her best to produce the best code possible in the time given, and not cut corners, then the code is as good as it can be.

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: What is good code?

Posted: Feb 28, 2005 10:03 AM

> I almost agree, but I would say:
>
> primary goals:
>
> * Easy to read, understand and use
> * Easy to change/modify
> * Simple as posible

A small but significant oversight is: "does what it should" or something comparable. Consider the program:

int main() {
  return 0;
}

This clearly satisfies your primary goals for every single possible set of software requirements. ;-)

Dan Perl

Posts: 28
Nickname: nanov
Registered: Sep, 2004

Re: What is good code?

Posted: Feb 28, 2005 10:13 AM

> > I almost agree, but I would say:
> >
> > primary goals:
> >
> > * Easy to read, understand and use
> > * Easy to change/modify
> > * Simple as posible
>
> A small but significant oversight is: "does what it
> should" or something comparable. Consider the program:
>
>

> int main() {
>   return 0;
> }
>

>
> This clearly satisfies your primary goals for every single
> possible set of software requirements. ;-)

I agree with you. I strongly believe that the priorities in Nicolas's list should be reversed. His secondary goals should be primary.

Steven E. Newton

Posts: 137
Nickname: cm
Registered: Apr, 2003

Re: What is good code?

Posted: Feb 28, 2005 10:18 AM

> Good code should address the following issues with roughly
> the following priority:
>
> 1. It should be very high in business value.
> 2. Test coverage should be near 100%
> 3. It should be simple.
> 4. It should have as little duplication as possible.
> 5. It should be expressive.
>

I'd refine these to just 3.
1. It should be simple.
2. It should have as little duplication as possible.
3. It should have nothing that is not necessary.

To clarify #3, code written with lots of things that really aren't needed is low in quality, for various reasons. Often it is disorganized to the point of obfuscation. Consider how you'd feel about an expository book or article that rambled afield in irrelevant topics.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: What is good code?

Posted: Feb 28, 2005 12:48 PM

> I consider these issues to be important. However, I
> consider the intent of the programmer to be more
> important. If the programmer is trying his/her best to
> produce the best code possible in the time given, and not
> cut corners, then the code is as good as it can be.

Comedy? A mediocre programmer trying their best produces code that is as good as it can be.

Dan Perl

Posts: 28
Nickname: nanov
Registered: Sep, 2004

Re: What is good code?

Posted: Feb 28, 2005 1:32 PM

> Comedy? A mediocre programmer trying their best
> produces code that is as good as it can be.

I'm not sure what your intent was, but if you meant to be as derogatory as your tone sounds to me, then yours was not a quality posting.

I think Bob's main point is to evangelize quality code. I agree with him on that and I welcome his effort, even I disagree with the way he has done that in some of his postings. Then, on the other hand, maybe it's just my resistance to any kind of evangelization.

I meant to say this on other occasions in other threads in this forum and I will use this opportunity to finally say it. Some of us (me included) have been making statements that quality can be compromised for different reasons. It's a dangerous statement to make and I can understand Bob's reaction to that. However, I think that is the truth and I think statements saying that there should be absolutely no compromise in quality are just as dangerous. Everything in life is made of compromises and trade-offs. And finding the right balance, the right compromises and the right trade-offs are a very important part of our profession.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: What is good code?

Posted: Feb 28, 2005 1:43 PM

> > Comedy? A mediocre programmer trying their best
> > produces code that is as good as it can be.
>
> I'm not sure what your intent was, but if you meant
> to be as derogatory as your tone sounds to me, then yours
> was not a quality posting.

(The quality the posting lacked was context.)

"If the programmers are mediocre, the product will be too."

http://groups-beta.google.com/group/comp.software.extreme-programming/msg/76318e55657052b4

Girts Kalnins

Posts: 23
Nickname: smejmoon
Registered: May, 2003

Re: What is good code?

Posted: Feb 28, 2005 2:42 PM

> 4. It should have as little duplication as possible.
> 5. It should be expressive.

I would sacrifice no-duplication for expressivenes. (Actualy that's almost the only reason. Other being security, other business reasons)

> 3. It should be simple.

In a long term that is impossible :)

Flat View: This topic has 35 replies on 3 pages [ 1 2 3 | » ]

Previous Topic

Next Topic