469,313 Members | 2,570 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,313 developers. It's quick & easy.

Reading great code

Hello!

In his recent newsletter embedded expert Jack Ganssle says that
programming students, as well as professional developers should readh
"great code" (hight quality/well-crafted code that works). He even
gives to examples. One is uC/OS-II operating system and the other is
TCP/IP stack for said system.
Do you know of other good examples of elegant and high-quality code
that is publicly available so that developers may look at it and learn?

It would be interesting to see it and may be even discuss why it is so
great.

Oct 13 '06 #1
42 1947
Hello!
>
In his recent newsletter embedded expert Jack Ganssle says that
programming students, as well as professional developers should readh
"great code" (hight quality/well-crafted code that works). He even
gives to examples. One is uC/OS-II operating system and the other is
TCP/IP stack for said system.
Do you know of other good examples of elegant and high-quality code
that is publicly available so that developers may look at it and learn?

It would be interesting to see it and may be even discuss why it is so
great.
Most programmers never reach the level where they're capable of writing
"great" code. How you even define "great" is debatable as there's a lot
of artistic license involved. It's not a hard science. However, those who
can consistently do it intrinsically understand how to convert program
requirements into beautiful code similar to the way a grandmaster at chess
intrinsically understands how to move his pieces around the board. It's a
combination of various mental "chunking" skills achieved after years of
practice (i.e., the ability to quickly and effortlessly see through a
problem without having to dwell on the constituent parts comprising that
problem). From this you can create an elegant solution without having to
think about it too much. It's hard to teach this to others however. You can
demonstrate a lot of sound principles but it takes tremendous practice and a
certain innate ability to master it yourself. Unfortunately, based on my own
experience, most people are incapable of it just like most can never become
a great chess player no matter how hard they try (even with Gary Kasparov as
your teacher). My own advice would be simple however. Make all your code as
generic and reusable (and robust) as possible. 95% or more of almost any
program can be made this way but 95% of all programmers don't understand
this fundamental rule. It's the hallmark of a great programmer however (if
you can master it you'll be on your way to writing "great" code - if you
want to take this offline I can send you some well documented C++ samples to
demonstrate).
Oct 13 '06 #2
gt8887b wrote:
Hello!

In his recent newsletter embedded expert Jack Ganssle says that
programming students, as well as professional developers should readh
"great code" (hight quality/well-crafted code that works). He even
gives to examples. One is uC/OS-II operating system and the other is
TCP/IP stack for said system.
Do you know of other good examples of elegant and high-quality code
that is publicly available so that developers may look at it and learn?

It would be interesting to see it and may be even discuss why it is so
great.
It's old (1976) and it's Pascal, but . . .

For my money, the best programming technique book ever is "Algorithms + Data
Structures = Programs", by Wirth (ISBN 0-13-022418-9). Elegant algorithms,
artfully implemented, and he illustrates somewhat the process of creation
(including sometimes the messiness and false starts) rather than just presenting
finished programs which seem to come from thin air.

FWIW, I have used uC/OS-II and agree that it is excellent code as well - it has
that same quality of being "straight to the point". The author (Labrosse)
explains his code well in the accompanying book along with many useful OS concepts.

Regards,
-rick-
Oct 14 '06 #3
John Browning <no_spam@_nospam.comwrote:

<snip>
My own advice would be simple however. Make all your code as
generic and reusable (and robust) as possible. 95% or more of almost any
program can be made this way but 95% of all programmers don't understand
this fundamental rule.
Robust I can agree with. Reusable less so - because in my experience,
the more reusable and generic you make it, the more complex it has to
be in order to accomplish the one task you have at hand. I often find
that I then never reuse the component in question, having gone to all
the trouble of making it reusable. These days, I build things in a less
reusable way until I can see that I've got code which *could* be reused
with a bit of a tweak. At that point with the appropriate unit tests in
place, it's usually not too hard to make the changes while keeping the
original use working.

If you know for sure that you actually need the code to be generic from
the start, that's a different matter of course.

This is often known as "YAGNI": "You Ain't Gonna Need It"

See http://c2.com/xp/YouArentGonnaNeedIt.html or
http://en.wikipedia.org/wiki/You_Ain't_Gonna_Need_It

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Oct 14 '06 #4
"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP************************@msnews.microsoft.c om...
>My own advice would be simple however. Make all your code as
generic and reusable (and robust) as possible. 95% or more of almost any
program can be made this way but 95% of all programmers don't understand
this fundamental rule.

Robust I can agree with. Reusable less so - because in my experience,
the more reusable and generic you make it, the more complex it has to
be in order to accomplish the one task you have at hand.
IMHO, this is only partially true.

In particular, one characteristic of a truly great programmer is to be able
to abstract a problem to the simplest form, which can often be a more
general, reusable solution rather than coding for some specific case.

It just depends on the problem, and I do agree that it's usually more
valuable to get something working first, and then improve, generalize, etc.
as needed. But IMHO some of the most elegant code also turns out to be some
of the most generic.

If the code, in being general, winds up with a bunch of special cases or
other extra conditional handling, then that's not what I'm talking about.
That's not an example of abstracting a problem...that's an example of
weighing down what ought to be simple code with a bunch of baggage. :) I'm
talking about seeing the forest for the trees and solving something in a
general way because that's the most efficient, least-complicate way to code
it.

It does happen. :)

As an added benefit to this approach, if one has truly abstracted a problem
to its simplest form, that often leads to the simplest implementation, which
has a direct effect on the robustness of the solution.

IMHO it's not an either/or thing. Sometimes it's better to solve the
problem in a very specific way, sometimes it's better to solve it in a more
general way. Part of the art of programming is knowing the difference. :)

Pete
Oct 14 '06 #5
Robust I can agree with. Reusable less so - because in my experience,
the more reusable and generic you make it, the more complex it has to
be in order to accomplish the one task you have at hand. I often find
that I then never reuse the component in question, having gone to all
the trouble of making it reusable. These days, I build things in a less
reusable way until I can see that I've got code which *could* be reused
with a bit of a tweak. At that point with the appropriate unit tests in
place, it's usually not too hard to make the changes while keeping the
original use working.

If you know for sure that you actually need the code to be generic from
the start, that's a different matter of course.

This is often known as "YAGNI": "You Ain't Gonna Need It"
I couldn't disagree more :) The correlation between generic software and
successful software is simply overwhelming. When things are written
generically from the outset (and properly documented), you soon end up with
a large repository of stable and reusbable code. This is code that you and
your colleagues can become familiar and comfortable with and you can reuse
it over and over again across different projects. Every organization should
have a central library just like this (peer reviewed and properly
controlled). When things aren't done this way (almost always), I guarantee
that it's only a matter of time before you have very serious and expensive
problems on your hands (from code bloat to instability to serious
maintainance issues, etc.). Just about every software organization has these
problems in abundance because they don't follow this rule and I've witnessed
it first-hand over and over and over again (ad nauseam). It far more
expensive (and not just in $) by not doing things this way and it's the most
important thing I've learned after 24 years in the field.
Oct 14 '06 #6
Jon Skeet [C# MVP] wrote:
Robust I can agree with. Reusable less so - because in my experience,
the more reusable and generic you make it, the more complex it has to
be in order to accomplish the one task you have at hand.
True. On the other hand, code that is supposed to be reusable is often
more robust than code that only seek to solve a specific problem. So
making code more reusable should make it more robust, even if the code
never actually will be reused.

This is of course unless, as you mentioned, making it more reusable also
adds too much complexity to the code.

To solve a part of a problem in a reusable way may also help you to make
the main part of a problem more streamlined, and make the special cases
fit into the standard model instead of adjusting the standard model for
every special case. So sometimes thinking in terms of reusability makes
the code less complex instead of more.
I often find
that I then never reuse the component in question, having gone to all
the trouble of making it reusable. These days, I build things in a less
reusable way until I can see that I've got code which *could* be reused
with a bit of a tweak. At that point with the appropriate unit tests in
place, it's usually not too hard to make the changes while keeping the
original use working.
I experience that too.

I also use that method sometimes to produce code that I know should be
reusable in the end. By first implementing the different cases with
specific code makes it easier to figure out the similarities between the
cases to see what should go into the reusable code.
Oct 14 '06 #7
Robust I can agree with. Reusable less so - because in my experience,
the more reusable and generic you make it, the more complex it has to
be in order to accomplish the one task you have at hand.
IME, this is not true unless you are trying to solve too many problems at
once. I've found that the best and most efficient way to implement something
is to first create a solution for the generic case (like a list class) and
then derive from that implementation for specific use (like a sorted list
class). This many times results in less complex and more robust code. The
amount of code might be larger compared to writing the specific
implementation directly, but that doesn't automatically indicate that the
code is more complex.
--
Regards, Peter
Oct 14 '06 #8
John,

Your word artistic did hit me, for that it is worth to read the book from
Ogilvy, nothing to do with developing however, in my idea should every
developer read that. It gives more knowledge to a developer than those
thousands of on technique based books it in my idea.

http://www.profitadvisors.com/ogilvy.shtml

He is writing as well about artists, those who he helps in his bureau direct
to find another job at his concurrent.

The job is in my idea to make hings maintainable, if you see discussions on
this dotNet boards between Jon and me it is mostly that Jon is more about
the artistic code and me about the maintainable code (although Jon wants as
well maintainable code is he in my idea staying an artist).

Therefore what is great code has always a point of view. Although I am in
fact as well an artist, and like to write very clever code where less
commands are used, is that in my idea good as hobby, not for real live.

Cor
"John Browning" <no_spam@_nospam.comschreef in bericht
news:%2****************@TK2MSFTNGP02.phx.gbl...
>Hello!

In his recent newsletter embedded expert Jack Ganssle says that
programming students, as well as professional developers should readh
"great code" (hight quality/well-crafted code that works). He even
gives to examples. One is uC/OS-II operating system and the other is
TCP/IP stack for said system.
Do you know of other good examples of elegant and high-quality code
that is publicly available so that developers may look at it and learn?

It would be interesting to see it and may be even discuss why it is so
great.

Most programmers never reach the level where they're capable of writing
"great" code. How you even define "great" is debatable as there's a lot
of artistic license involved. It's not a hard science. However, those who
can consistently do it intrinsically understand how to convert program
requirements into beautiful code similar to the way a grandmaster at chess
intrinsically understands how to move his pieces around the board. It's a
combination of various mental "chunking" skills achieved after years of
practice (i.e., the ability to quickly and effortlessly see through a
problem without having to dwell on the constituent parts comprising that
problem). From this you can create an elegant solution without having to
think about it too much. It's hard to teach this to others however. You
can demonstrate a lot of sound principles but it takes tremendous practice
and a certain innate ability to master it yourself. Unfortunately, based
on my own experience, most people are incapable of it just like most can
never become a great chess player no matter how hard they try (even with
Gary Kasparov as your teacher). My own advice would be simple however.
Make all your code as generic and reusable (and robust) as possible. 95%
or more of almost any program can be made this way but 95% of all
programmers don't understand this fundamental rule. It's the hallmark of a
great programmer however (if you can master it you'll be on your way to
writing "great" code - if you want to take this offline I can send you
some well documented C++ samples to demonstrate).

Oct 14 '06 #9
Well, if all this debate, each person making some excellent points, and
almost all at odds with one another over those very points, doesn't point up
the greatest difficulty of mastering programming, I don't know what will.

In fact, I view the whole thing as a balancing act. Elegant software is a
beautiful thing to behold, and just as rare. For one thing, it just takes
too long to write, and we developers are constrained by time and money
considerations. Reusability is also a double-edged sword, and although I
believe John and Jon are both correct, their conflict is more one of
emphasis than perhaps they realize.

The real trick is to master skills that enable one to stay more or less
within the limits of what *can* be achieved, and that perfection that any
conscientious programmer desires to achieve in his/her work. Every developer
finds his/her own unique methodology to strive towards that "golden mean,"
and each is unique because we all have a unique combination of gifts and
liabilities.

All that said, reading "good" code is always a good idea. As for "great"
code, it's hard to draw the line between the 2, and even reading "bad" code
can be a worthwhile process, as long as one is looking at it as "bad." One
can observe and learn from the pitfalls that others have fallen into, as
well as from the examples of those who have attained a measure of skill.

The most important aspect of a programmer's personal development is the
drive to become perfect, a goal which, although impossible to attain, is
worth aiming at. What you seek is what you get, in the long run. Aim for the
stars, and someday, you'll at least reach the moon.

--
HTH,

Kevin Spencer
Microsoft MVP
Chicken Salad Shooter
http://unclechutney.blogspot.com

A man, a plan, a canal, a palindrome that has.. oh, never mind.

"John Browning" <no_spam@_nospam.comwrote in message
news:ew**************@TK2MSFTNGP02.phx.gbl...
>Robust I can agree with. Reusable less so - because in my experience,
the more reusable and generic you make it, the more complex it has to
be in order to accomplish the one task you have at hand. I often find
that I then never reuse the component in question, having gone to all
the trouble of making it reusable. These days, I build things in a less
reusable way until I can see that I've got code which *could* be reused
with a bit of a tweak. At that point with the appropriate unit tests in
place, it's usually not too hard to make the changes while keeping the
original use working.

If you know for sure that you actually need the code to be generic from
the start, that's a different matter of course.

This is often known as "YAGNI": "You Ain't Gonna Need It"

I couldn't disagree more :) The correlation between generic software and
successful software is simply overwhelming. When things are written
generically from the outset (and properly documented), you soon end up
with
<snip>
Oct 14 '06 #10
On Sat, 14 Oct 2006 07:17:17 +0100, Jon Skeet [C# MVP]
<sk***@pobox.comwrote:
>John Browning <no_spam@_nospam.comwrote:
>My own advice would be simple however. Make all your code as
generic and reusable (and robust) as possible. 95% or more of almost any
program can be made this way but 95% of all programmers don't understand
this fundamental rule.

Robust I can agree with. Reusable less so - because in my experience,
the more reusable and generic you make it, the more complex it has to
be in order to accomplish the one task you have at hand. I often find
that I then never reuse the component in question, having gone to all
the trouble of making it reusable. These days, I build things in a less
reusable way until I can see that I've got code which *could* be reused
with a bit of a tweak. At that point with the appropriate unit tests in
place, it's usually not too hard to make the changes while keeping the
original use working.

If you know for sure that you actually need the code to be generic from
the start, that's a different matter of course.
I agree with this 100%. The general is much harder to write than the
specific.

--
Posted via a free Usenet account from http://www.teranews.com

Oct 14 '06 #11
Well said

--
Regards, Peter
Oct 15 '06 #12
I agree with this 100%. The general is much harder to write than the
specific.
Not all code can (or should) be generalized. Only when it is apparent that a
generalization is of use and (at least somewhat) easy to accomplish, should
that path be considered. I believe that when it is hard to write a general
implementation, it is an indication that you should probably not even try.
OTOH, if a generalization "falls in your lap", it is often easier to write
than specializing directly.

Finding solutions to programming problems is a lot about "seeing it". Even
if you understand the requirements on a basic level, it isn't until you get
that "I know how to solve this" feeling that you truly know if the solution
lends itself to generalization. It is, as much in live, depending on the
situation.

I have been in the situation many times where I have written a specialized
implementation and several days, weeks or even months later realized that it
could be generalized for other use and subsequently rewritten the code.
Programming (to me) is an iterative and evolutionary process where I
commonly return to old code several times to tweak, rewrite and optimize.
Hopefully this results in great (or at least good) code at some point. The
trick is to know when enough is enough :)
--
Regards, Peter
Oct 15 '06 #13
Ben Newsam wrote:
The general is much harder to write than the specific.
Often true, but not always because you get less code for more work.
Sometimes it's mostly because the generalized code that you get is far
superior to the specialized code. You can end up with code that is more
efficient and more maintainable because it's simpler and more elegant.
Oct 15 '06 #14
Cor Ligthert [MVP] wrote:
Therefore what is great code has always a point of view. Although I am in
fact as well an artist, and like to write very clever code where less
commands are used, is that in my idea good as hobby, not for real live.
I agree fully. I think that it's very good for a programmer to write
extreme code as a hobby. Size optimizing assembler code or writing
clever one-liners is something that you rarely do in production code.

Experimenting with code should mostly be done for it's own sake, and not
when you are supposed to whip up some decent, stable, working code for
some moderately difficult task.

What you learn from experimenting with code will show up in the
production code anyway, as knowledge and elegant solutions, not as
clever and tricky ways of using things in a way they werent really ment
to be used.

:)
Oct 15 '06 #15
On 13 Oct 2006 16:11:47 -0700, "gt8887b" <gt*****@gmail.comwrote:
>Hello!

In his recent newsletter embedded expert Jack Ganssle says that
programming students, as well as professional developers should readh
"great code" (hight quality/well-crafted code that works). He even
gives to examples. One is uC/OS-II operating system and the other is
TCP/IP stack for said system.

Do you know of other good examples of elegant and high-quality code
that is publicly available so that developers may look at it and learn?

It would be interesting to see it and may be even discuss why it is so
great.
The key to writing elegant code is to start with a well considered
design.

regards
A.G.
Oct 15 '06 #16
On Sun, 15 Oct 2006 15:36:19 +0200, G÷ran Andersson <gu***@guffa.com>
wrote:
>
Experimenting with code should mostly be done for it's own sake, and not
when you are supposed to whip up some decent, stable, working code for
some moderately difficult task.

What you learn from experimenting with code will show up in the
production code anyway, as knowledge and elegant solutions, not as
clever and tricky ways of using things in a way they werent really ment
to be used.
This is absolutely correct as it describes part of the design process.
Any code written during the design process is strictly throw-away
material written for clarification of concept. In contrast a
programmer's code is often considered "too valuable" to discard.

regards
A.G.
Oct 15 '06 #17
G÷ran Andersson <gu***@guffa.comwrote:
Ben Newsam wrote:
The general is much harder to write than the specific.
Often true, but not always because you get less code for more work.
Sometimes it's mostly because the generalized code that you get is far
superior to the specialized code. You can end up with code that is more
efficient and more maintainable because it's simpler and more elegant.
That's true - *if* you use the general functionality. It is usually
harder to understand the general functionality than specific
functionality. That's fine if you actually use it - but if you're only
ever going to use the code in one particular way, there's not a lot of
point in making it hugely flexible.

Of course, when you then find yourself doing something similar,
*that's* the time to refactor the previous code and build the more
general functionality.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Oct 15 '06 #18
Registered User <n4***@ix.netcom.comwrote:
What you learn from experimenting with code will show up in the
production code anyway, as knowledge and elegant solutions, not as
clever and tricky ways of using things in a way they werent really ment
to be used.
This is absolutely correct as it describes part of the design process.
Any code written during the design process is strictly throw-away
material written for clarification of concept. In contrast a
programmer's code is often considered "too valuable" to discard.
That assumes a design process which comes strictly ahead of the real
code. With TDD, although you need the high level architecture ahead of
time, the design of the public contract often emerges as you try to
write tests which use the production class in the easiest way. Guessing
exactly what will be easy to use ahead of time is often very hard
indeed - and a waste of time, IMO, when writing tests can get you to
the end result faster, and with demonstrably working code.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Oct 15 '06 #19
In fact, I view the whole thing as a balancing act. Elegant software is a
beautiful thing to behold, and just as rare. For one thing, it just takes
too long to write, and we developers are constrained by time and money
considerations. Reusability is also a double-edged sword, and although I
believe John and Jon are both correct, their conflict is more one of
emphasis than perhaps they realize.
Yes, it definitely is a balancing act. However, the "constrained by time and
money" argument is one I've heard far too many times over the years. In
practice it doesn't wash however because one is always restrained by
resources in every endeavour in life. The goal is not to achieve Utopian
perfection which clearly isn't possible (or even definable), but to strive
for reusablity as best as you can given your limited resources. When you
look at almost any software however, what you see is not code that was
restrained by resource limitations, but code that's indicative of people who
are just bad at what they do. Their code wouldn't improve much if you gave
them all the time and money in the world to work with (within reason of
course). OTOH, in the hands of someone who does know what they're doing
(rare as that might be), the same code will be reasonably clean and generic
even with the very same constraints in place (in spite of the naysayers who
claim this can't be done - it certainly can be). And why is that? Because
they understand that program correctness is incredibly difficult to achieve
otherwise. That by not doing things this way from the outset, all the
negative fallout associated with most software will soon manifest itself.
You therefore have it it backwards. The time and money issues only rear
their ugly heads in the aftermath of a poorly written program (and in fact
are primarily caused by it), not during its initial creation.
Oct 15 '06 #20
On Sun, 15 Oct 2006 17:34:56 +0100, Jon Skeet [C# MVP]
<sk***@pobox.comwrote:
>Registered User <n4***@ix.netcom.comwrote:
>What you learn from experimenting with code will show up in the
production code anyway, as knowledge and elegant solutions, not as
clever and tricky ways of using things in a way they werent really ment
to be used.
>This is absolutely correct as it describes part of the design process.
Any code written during the design process is strictly throw-away
material written for clarification of concept. In contrast a
programmer's code is often considered "too valuable" to discard.

That assumes a design process which comes strictly ahead of the real
code. With TDD, although you need the high level architecture ahead of
time, the design of the public contract often emerges as you try to
write tests which use the production class in the easiest way. Guessing
exactly what will be easy to use ahead of time is often very hard
indeed - and a waste of time, IMO, when writing tests can get you to
the end result faster, and with demonstrably working code.
The term "guessing exactly"applies more to the long odds of winning a
lottery than any sort of true application/system design. The whole
purpose of the design stage is to eliminate much if not all of the
guess work. The last D in TDD stands for development which encompasses
much more than trying to write production code. A great deal of coding
and testing can/should be done during the design process. The
validation of a particular design is the production of a functional
proof of concept. Granted more time is taken for the design phase but
development difficulties are front-loaded into the process. The
production phase is simplified as the programmers have fewer issues to
consider and fewer questions to ask.

regards
A.G.
Oct 15 '06 #21
Kevin Spencer wrote:
Well, if all this debate, each person making some excellent points, and
almost all at odds with one another over those very points, doesn't point up
the greatest difficulty of mastering programming, I don't know what will.
I can't help thinking that this difficulty is because code isn't great
in isolation, it's great in relation to its purpose. My line is
mission-critical applications (my interest in C# is as a hobbyist,
though I'm keeping a professional eye on spec#), and the greatest
mission-critical code I've ever seen has been spectacularly dull,
vanilla coding. If I could post any of the code here, most folks would
just shrug and say "so what?" What made it great was the design work
that had gone into getting to the point where the coding was really
/really/ simple, and the willpower of the coders who resisted the
temptation to do any fancy tricks to make it more "elegant" or add
unnecessary bells and whistles (such as trying to make code reuseable:
software re-use has led to some major incidents, so although the
mission-critical community does use reuse -- every time the programmer
tells the compiler to allocate an array they're using re-use at some
level -- they do treat it with a great deal of caution).
Oct 15 '06 #22
unnecessary bells and whistles (such as trying to make code reuseable:
software re-use has led to some major incidents, so although the
mission-critical community does use reuse -- every time the programmer
tells the compiler to allocate an array they're using re-use at some
level -- they do treat it with a great deal of caution).
Do you use the Common Language Runtime Library? Then you use reusable code.
Unless you write your own MSIL, you're using a *lot* of reusable code.

--
HTH,

Kevin Spencer
Microsoft MVP
Chicken Salad Shooter
http://unclechutney.blogspot.com

A man, a plan, a canal, a palindrome that has.. oh, never mind.

"Tim Rowe" <ti*@remove.if.not.spam.digitig.co.ukwrote in message
news:45**********************@ptn-nntp-reader02.plus.net...
Kevin Spencer wrote:
>Well, if all this debate, each person making some excellent points, and
almost all at odds with one another over those very points, doesn't point
up the greatest difficulty of mastering programming, I don't know what
will.

I can't help thinking that this difficulty is because code isn't great in
isolation, it's great in relation to its purpose. My line is
mission-critical applications (my interest in C# is as a hobbyist, though
I'm keeping a professional eye on spec#), and the greatest
mission-critical code I've ever seen has been spectacularly dull, vanilla
coding. If I could post any of the code here, most folks would just shrug
and say "so what?" What made it great was the design work that had gone
into getting to the point where the coding was really /really/ simple, and
the willpower of the coders who resisted the temptation to do any fancy
tricks to make it more "elegant" or add unnecessary bells and whistles
(such as trying to make code reuseable: software re-use has led to some
major incidents, so although the mission-critical community does use
reuse -- every time the programmer tells the compiler to allocate an array
they're using re-use at some level -- they do treat it with a great deal
of caution).

Oct 15 '06 #23
Yes, it definitely is a balancing act. However, the "constrained by time
and money" argument is one I've heard far too many times over the years.
In practice it doesn't wash however because one is always restrained by
resources in every endeavour in life.
I'm glad you don't have bosses that give you unreasonable deadlines, and
plenty of help. Either that, or you write extremely small applications, well
back from the bleeding edge of software technology, with few features.
Personally, in over a dozen years of programming, I've always had to "fish
or cut bait" at some point, some point that requires me to refactor a good
bit less than I'd like to.

--
HTH,

Kevin Spencer
Microsoft MVP
Chicken Salad Shooter
http://unclechutney.blogspot.com

A man, a plan, a canal, a palindrome that has.. oh, never mind.

"John Browning" <no_spam@_nospam.comwrote in message
news:u2**************@TK2MSFTNGP04.phx.gbl...
>In fact, I view the whole thing as a balancing act. Elegant software is a
beautiful thing to behold, and just as rare. For one thing, it just takes
too long to write, and we developers are constrained by time and money
considerations. Reusability is also a double-edged sword, and although I
believe John and Jon are both correct, their conflict is more one of
emphasis than perhaps they realize.

Yes, it definitely is a balancing act. However, the "constrained by time
and money" argument is one I've heard far too many times over the years.
In practice it doesn't wash however because one is always restrained by
resources in every endeavour in life. The goal is not to achieve Utopian
perfection which clearly isn't possible (or even definable), but to strive
for reusablity as best as you can given your limited resources. When you
look at almost any software however, what you see is not code that was
restrained by resource limitations, but code that's indicative of people
who are just bad at what they do. Their code wouldn't improve much if you
gave them all the time and money in the world to work with (within reason
of course). OTOH, in the hands of someone who does know what they're doing
(rare as that might be), the same code will be reasonably clean and
generic even with the very same constraints in place (in spite of the
naysayers who claim this can't be done - it certainly can be). And why is
that? Because they understand that program correctness is incredibly
difficult to achieve otherwise. That by not doing things this way from the
outset, all the negative fallout associated with most software will soon
manifest itself. You therefore have it it backwards. The time and money
issues only rear their ugly heads in the aftermath of a poorly written
program (and in fact are primarily caused by it), not during its initial
creation.

Oct 15 '06 #24
Thank you all very much for your replies and insight.

Let me pitch in on what the definition of "great" is. In my opinion
"geat code" has these important characteristics:

1. It works - fulfills requirements and has no defects(bugs) that
affect its usefullness
2. It is elegant - uses consistent design pattern and coding style
3. It is maintainable - it is easy to understand what code does, how it
works, and make changes to it

As far as using "tricks" and writing "clever code"... I've seen far
too many examples where such efforts become counter-productive.

One of the biggest pitfalls is using "clever" code to make code faster.
Much too often this results in writing convoluted and error-prone code
to optimize some part of the program that does not need to be optimized!

Oct 16 '06 #25
Registered User <n4***@ix.netcom.comwrote:
That assumes a design process which comes strictly ahead of the real
code. With TDD, although you need the high level architecture ahead of
time, the design of the public contract often emerges as you try to
write tests which use the production class in the easiest way. Guessing
exactly what will be easy to use ahead of time is often very hard
indeed - and a waste of time, IMO, when writing tests can get you to
the end result faster, and with demonstrably working code.

The term "guessing exactly"applies more to the long odds of winning a
lottery than any sort of true application/system design. The whole
purpose of the design stage is to eliminate much if not all of the
guess work.
Requirements change. It's a fact of life, unfortunate as it is. How are
you going to eliminate that? You can *guess* the areas where it will
change, and design accordingly, but that will always be guesswork.
The last D in TDD stands for development which encompasses
much more than trying to write production code. A great deal of coding
and testing can/should be done during the design process. The
validation of a particular design is the production of a functional
proof of concept. Granted more time is taken for the design phase but
development difficulties are front-loaded into the process. The
production phase is simplified as the programmers have fewer issues to
consider and fewer questions to ask.
Well, I'm not a fan of the big up-front design. Architecture, yes - but
when you get to the point of individual classes, I think a bit of
"just-in-time" design is fine.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Oct 16 '06 #26
Kevin Spencer wrote:
>unnecessary bells and whistles (such as trying to make code reuseable:
software re-use has led to some major incidents, so although the
mission-critical community does use reuse -- every time the programmer
tells the compiler to allocate an array they're using re-use at some
level -- they do treat it with a great deal of caution).

Do you use the Common Language Runtime Library? Then you use reusable code.
Unless you write your own MSIL, you're using a *lot* of reusable code.
I use it as a hobbyist. As I said, professionally I don't use C#. I'm
not aware of any mission-critical applications that use .NET (or Mono),
and the more critical applications use specialist operating systems (and
compilers, and libraries) or no operating system at all (except perhaps
as a loader), for just the reason you've spotted.
Oct 16 '06 #27
I'm glad you don't have bosses that give you unreasonable deadlines, and
plenty of help. Either that, or you write extremely small applications,
well back from the bleeding edge of software technology, with few
features. Personally, in over a dozen years of programming, I've always
had to "fish or cut bait" at some point, some point that requires me to
refactor a good bit less than I'd like to.
You're situation is the norm, not the exception. One can still write
reasonably clean code even in a sweatshop. You can cut corners and still do
a clean job of it. Nobody has the luxury of working in a think tank with an
unlimited amount of time on their hands. We all face the same pressures yet
most of the bad code you encounter in the real world has little to do with
tight deadlines. The mess you see masquerading as software in most companies
became that way because the people who wrote it were novices. You can
clearly see it in their code. The pervasive sloppiness and poor design and
outright mechanical mistakes had little to do with deadlines. You don't see
the same problems in code written by those have mastered their craft
however. They face the very same deadlines yet their code remains reasonably
robust and extensible. It stands the test of time. It's the key to
successful software and those who don't follow it now always pay a heavy
price for it later.
Oct 16 '06 #28
"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP************************@msnews.microsoft.c om...
Registered User <n4***@ix.netcom.comwrote:
<snip>
Well, I'm not a fan of the big up-front design. Architecture, yes - but
when you get to the point of individual classes, I think a bit of
"just-in-time" design is fine.
<snip>

I agree, and here's why: Software design, like software development, is (or
should be) an iterative process, in which certain design features suggest
themselves during the development process. A well-structured, well-defined
"10,000- foot" architecture is very important, but below that point there
should be "wiggle-room" to allow for crative insights to occur as the
software takes shape. In fact, most software companies, Microsoft included,
implement ideas from beta testers during that phase of the process, which
seems to support some aspect of this idea.

Again, it's all a rather complex balancing act.

--
HTH,

Kevin Spencer
Microsoft MVP
Chicken Salad Shooter
http://unclechutney.blogspot.com

A man, a plan, a canal, a palindrome that has.. oh, never mind.
Oct 16 '06 #29
I use it as a hobbyist. As I said, professionally I don't use C#. I'm not
aware of any mission-critical applications that use .NET (or Mono), and
the more critical applications use specialist operating systems (and
compilers, and libraries) or no operating system at all (except perhaps as
a loader), for just the reason you've spotted.
I'm afraid you're just plain wrong here. First of all, if you use *any*
programming language above the Assembler level (which is, in fact, a library
of reusable machine code), you use various libraries (DLLs), as well as your
own custom code. The C language, for example, can't be used without at the
very least the stdio library. C++ has the MFC library. Java has the J2SE
library. The .Net platform is no different.

Second, there are *lots* of mission-critical applications out there written
with the .Net platform. It is not a prototyping platform, any more than Java
is a prototyping platform.

The only truly non-reusable code is machine code.

--
HTH,

Kevin Spencer
Microsoft MVP
Chicken Salad Shooter
http://unclechutney.blogspot.com

A man, a plan, a canal, a palindrome that has.. oh, never mind.

"Tim Rowe" <ti*@remove.if.not.spam.digitig.co.ukwrote in message
news:45**********************@ptn-nntp-reader02.plus.net...
Kevin Spencer wrote:
>>unnecessary bells and whistles (such as trying to make code reuseable:
software re-use has led to some major incidents, so although the
mission-critical community does use reuse -- every time the programmer
tells the compiler to allocate an array they're using re-use at some
level -- they do treat it with a great deal of caution).

Do you use the Common Language Runtime Library? Then you use reusable
code. Unless you write your own MSIL, you're using a *lot* of reusable
code.
I use it as a hobbyist. As I said, professionally I don't use C#. I'm not
aware of any mission-critical applications that use .NET (or Mono), and
the more critical applications use specialist operating systems (and
compilers, and libraries) or no operating system at all (except perhaps as
a loader), for just the reason you've spotted.

Oct 16 '06 #30
Kevin Spencer wrote:
>I use it as a hobbyist. As I said, professionally I don't use C#. I'm not
aware of any mission-critical applications that use .NET (or Mono), and
the more critical applications use specialist operating systems (and
compilers, and libraries) or no operating system at all (except perhaps as
a loader), for just the reason you've spotted.

I'm afraid you're just plain wrong here. First of all, if you use *any*
programming language above the Assembler level (which is, in fact, a library
of reusable machine code), you use various libraries (DLLs), as well as your
own custom code. The C language, for example, can't be used without at the
very least the stdio library. C++ has the MFC library. Java has the J2SE
library. The .Net platform is no different.
None of those languages is used for the sort of application I am dealing
with, at least not at the higher criticalities. Nor are their associated
libraries. And even when the languages used do have code libraries
available, those libraries are generally not used unless they have been
specifically designed with mission-critical applications in mind.
Second, there are *lots* of mission-critical applications out there written
with the .Net platform. It is not a prototyping platform, any more than Java
is a prototyping platform.
I'm not suggesting that .net is a prototyping platform; I know it's
better than that. There's a distinction between real-world applications
in general and mission-critical applications in particular. I'm dealing
with applications that can kill a few hundred people at a time if they
go wrong (and I work with people who are dealing with applications that
can kill a few thousand people at a time). I'm not aware of .net being
in used that sort of application, and I'd be very worried if it were,
not because there's anything wrong with .net but because that's not what
..net is designed to be good at. There's a lot of complexity in .net and
in MS Windows which gives the richness that AFAICS is a great help in
the cost-effective development of commercial-strength applications but
which is a problem for mission-critical. The hazards can't be completely
eliminated, but the more of them that are taken out of the system the
better.

Yes, as soon as I use a compiler I'm doing some code reuse courtesy of
the compiler's code generator. I was careful not to say that there was
no reuse, just that it's treated with a great deal of caution. Oh, and
on the more critical projects I've worked on, the I/O routines /have/
been custom-written in assembler. Before you ask, the correctness of
the microprocessor is a continuing issue, but it's a question of
eliminating unnecessary risks and being aware of (and managing) the
risks that are left.
Oct 16 '06 #31
On Mon, 16 Oct 2006 07:30:52 +0100, Jon Skeet [C# MVP]
<sk***@pobox.comwrote:

- snippage -
>
Requirements change. It's a fact of life, unfortunate as it is. How are
you going to eliminate that? You can *guess* the areas where it will
change, and design accordingly, but that will always be guesswork.
The relationship between project owners and project managers is
bizarre. My experiences indicate the project manager ends up writing
the requirements document and submits it for the project owner's
approval. Too few project owners are able to provide cognizant details
with out much prodding and poking. "Is this what you mean?" is an
oft-asked question during these interrogations.

What to do when the requirements change midstream? The first thing to
do is determine if the change is indeed a requirement. Project owners
generally are not aware of the differences between requirements,
features and chrome. Pointing to the calendar and its made up
deadlines can often turn a new requirement into a feature for the next
version.

-more snippage -
>
Well, I'm not a fan of the big up-front design. Architecture, yes - but
when you get to the point of individual classes, I think a bit of
"just-in-time" design is fine.
I agree there will always be some need for JIT tweaking but not every
programmer has the required skills and mindset. Understanding
abstraction and thinking abstractly represent two different levels.

Thank you for the enjoyable exchange of ideas and opinions.

regards
A.G.

Oct 16 '06 #32
..Net is used by the U.S. Military. Is that mission-critical enough for you?

--
HTH,

Kevin Spencer
Microsoft MVP
Chicken Salad Shooter
http://unclechutney.blogspot.com

A man, a plan, a canal, a palindrome that has.. oh, never mind.

"Tim Rowe" <ti*@remove.if.not.spam.digitig.co.ukwrote in message
news:45**********************@ptn-nntp-reader02.plus.net...
Kevin Spencer wrote:
>>I use it as a hobbyist. As I said, professionally I don't use C#. I'm
not aware of any mission-critical applications that use .NET (or Mono),
and the more critical applications use specialist operating systems (and
compilers, and libraries) or no operating system at all (except perhaps
as a loader), for just the reason you've spotted.

I'm afraid you're just plain wrong here. First of all, if you use *any*
programming language above the Assembler level (which is, in fact, a
library of reusable machine code), you use various libraries (DLLs), as
well as your own custom code. The C language, for example, can't be used
without at the very least the stdio library. C++ has the MFC library.
Java has the J2SE library. The .Net platform is no different.

None of those languages is used for the sort of application I am dealing
with, at least not at the higher criticalities. Nor are their associated
libraries. And even when the languages used do have code libraries
available, those libraries are generally not used unless they have been
specifically designed with mission-critical applications in mind.
>Second, there are *lots* of mission-critical applications out there
written with the .Net platform. It is not a prototyping platform, any
more than Java is a prototyping platform.

I'm not suggesting that .net is a prototyping platform; I know it's better
than that. There's a distinction between real-world applications in
general and mission-critical applications in particular. I'm dealing with
applications that can kill a few hundred people at a time if they go wrong
(and I work with people who are dealing with applications that can kill a
few thousand people at a time). I'm not aware of .net being in used that
sort of application, and I'd be very worried if it were, not because
there's anything wrong with .net but because that's not what .net is
designed to be good at. There's a lot of complexity in .net and in MS
Windows which gives the richness that AFAICS is a great help in the
cost-effective development of commercial-strength applications but which
is a problem for mission-critical. The hazards can't be completely
eliminated, but the more of them that are taken out of the system the
better.

Yes, as soon as I use a compiler I'm doing some code reuse courtesy of the
compiler's code generator. I was careful not to say that there was no
reuse, just that it's treated with a great deal of caution. Oh, and on the
more critical projects I've worked on, the I/O routines /have/ been
custom-written in assembler. Before you ask, the correctness of the
microprocessor is a continuing issue, but it's a question of eliminating
unnecessary risks and being aware of (and managing) the risks that are
left.

Oct 16 '06 #33
Kevin Spencer wrote:
.Net is used by the U.S. Military. Is that mission-critical enough for you?
Depends what they use it for!
Oct 16 '06 #34
>That's true - *if* you use the general functionality. It is usually
>harder to understand the general functionality than specific
functionality. That's fine if you actually use it - but if you're only
ever going to use the code in one particular way, there's not a lot of
point in making it hugely flexible.
So true. Generalization for the sake of generalization is plain stupid. I
can't tell you how many times I've seen eager beavers trying to build base
classes to derive from and just ending up with a jumble of stuff that
doesn't work very well, barely hangs together and many times has a design
that doesn't even make sense. Keeping it simple is so hard for some people
and yet it is the only way to build code that works and that is robust and
safe.
>Of course, when you then find yourself doing something similar,
*that's* the time to refactor the previous code and build the more
general functionality.
Iteration and refactoring is a big part of writing good code. It might not
be good today, but it will be tomorrow!

This is a very interesting and refreshing discussion.

--
Regards, Peter
Oct 16 '06 #35
On Mon, 16 Oct 2006 10:41:03 -0400, Registered User
<n4***@ix.netcom.comwrote:
>The relationship between project owners and project managers is
bizarre. My experiences indicate the project manager ends up writing
the requirements document and submits it for the project owner's
approval. Too few project owners are able to provide cognizant details
with out much prodding and poking. "Is this what you mean?" is an
oft-asked question during these interrogations.
Easily summed up by "Ask them what they want, but give them what they
need".

--
Posted via a free Usenet account from http://www.teranews.com

Oct 17 '06 #36
Tim Rowe wrote:
Kevin Spencer wrote:
>I'm afraid you're just plain wrong here. First of all, if you use
*any* programming language above the Assembler level (which is, in
fact, a library of reusable machine code), you use various libraries
(DLLs), as well as your own custom code. The C language, for example,
can't be used without at the very least the stdio library. C++ has the
MFC library. Java has the J2SE library. The .Net platform is no
different.

None of those languages is used for the sort of application I am dealing
with, at least not at the higher criticalities. Nor are their associated
libraries. And even when the languages used do have code libraries
available, those libraries are generally not used unless they have been
specifically designed with mission-critical applications in mind.
Ada ?
>Second, there are *lots* of mission-critical applications out there
written with the .Net platform. It is not a prototyping platform, any
more than Java is a prototyping platform.

I'm not suggesting that .net is a prototyping platform; I know it's
better than that. There's a distinction between real-world applications
in general and mission-critical applications in particular. I'm dealing
with applications that can kill a few hundred people at a time if they
go wrong (and I work with people who are dealing with applications that
can kill a few thousand people at a time). I'm not aware of .net being
in used that sort of application, and I'd be very worried if it were,
not because there's anything wrong with .net but because that's not what
.net is designed to be good at. There's a lot of complexity in .net and
in MS Windows which gives the richness that AFAICS is a great help in
the cost-effective development of commercial-strength applications but
which is a problem for mission-critical. The hazards can't be completely
eliminated, but the more of them that are taken out of the system the
better.
Indeed the Java license contains:

"You acknowledge that Licensed Software is not designed or
intended for use in the design, construction, operation or maintenance
of any nuclear facility."

I don't know if MS has a similar clause for .NET ...

Arne
Oct 17 '06 #37
Arne Vajh°j wrote:
Tim Rowe wrote:
>None of those languages is used for the sort of application I am
dealing with, at least not at the higher criticalities. Nor are their
associated libraries. And even when the languages used do have code
libraries available, those libraries are generally not used unless
they have been specifically designed with mission-critical
applications in mind.

Ada ?
A safe subset of Ada is a common choice, yes.
I don't know if MS has a similar clause for .NET ...
I don't know either -- it's a long while since I read the license. But
untangling the bits of Windows that have such license restrictions is
certainly a challenge even at the lower criticalities.
Oct 17 '06 #38
>.Net is used by the U.S. Military. Is that mission-critical enough for
>you?
Depends what they use it for!
I'm afraid I'm not at liberty to say. There may be some public documents
available about some of it.

--
HTH,

Kevin Spencer
Microsoft MVP
Chicken Salad Shooter
http://unclechutney.blogspot.com

A man, a plan, a canal, a palindrome that has.. oh, never mind.

"Tim Rowe" <ti*@remove.if.not.spam.digitig.co.ukwrote in message
news:45**********************@ptn-nntp-reader02.plus.net...
Kevin Spencer wrote:
>.Net is used by the U.S. Military. Is that mission-critical enough for
you?
Depends what they use it for!

Oct 17 '06 #39
Kevin Spencer wrote:
>>.Net is used by the U.S. Military. Is that mission-critical enough for
you?
Depends what they use it for!

I'm afraid I'm not at liberty to say. There may be some public documents
available about some of it.
Understood -- just as I can't post examples of the sort of code I'm
talking about.

What it ultimately comes down to is that one is going to have a great
deal of difficulty showing compliance to the more rigorous levels of
international standards such as IEC61508 using /any/ mass-market
operating system (and I can't use .net without sitting it on top of a
mass-market operating system, can I?) And although there is some debate
about the details of what is in those standards, they do represent the
current expert view of best practice. But not all software in critical
systems is necessarily critical; if there are enough controls and
mitigations in place then once be able to be more relaxed about the
software element. So no matter how critical the overall application, we
wouldn't be able to tell whether a particular solution is appropriate
without seeing the full safety analysis (which is rarely public, so one
has to have confidence in the regulators).
Oct 17 '06 #40
It was often said that if MAD had ever been used in a real situation, it would
have failed. There was ever going to be one chance to use it.

Kevin Spencer wrote:
.Net is used by the U.S. Military. Is that mission-critical enough for you?
Oct 17 '06 #41
"Ian Semmel" <is***********@NOKUNKrocketcomp.com.auwrote in message
news:uy**************@TK2MSFTNGP02.phx.gbl...
It was often said that if MAD had ever been used in a real situation, it
would have failed. There was ever going to be one chance to use it.
MAD -was- used - that was the whole point. It deterred nuclear war by
assuring mutual destruction. As insane as it sounds, the proof of its
success is the current existence of New York City and Moscow.

///ark
Oct 17 '06 #42
Tim Rowe wrote:
Arne Vajh°j wrote:
>Ada ?

A safe subset of Ada is a common choice, yes.
Ada is actually a nice language.

Arne

PS: I don't know whether you are aware of it, but you can
use Ada and .NET together via mgnat.

Oct 17 '06 #43

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

7 posts views Thread by Santah | last post: by
6 posts views Thread by KevinD | last post: by
4 posts views Thread by sabads | last post: by
3 posts views Thread by Maxim Vexler | last post: by
4 posts views Thread by n_jaksic | last post: by
1 post views Thread by CARIGAR | last post: by
reply views Thread by zhoujie | last post: by
reply views Thread by harlem98 | last post: by
1 post views Thread by Geralt96 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.