L
E
Ebenezer
I favor the do it right path. The requirements can change on
you that way, but not to the extent that you have to throw it
all out and start over. In a Wall Street Journal article on
the best and worst jobs (software developer was rated no. 1)
a software developer was quoted, "You can't think that you'll
learn a skill now and that it will still be relevant in six
months." I disagree with that. It's important to work at
keeping up with new developments, but am not finding things
I've learned are being discarded that quickly.
Brian Wood
Ebenezer Enterprises
http://webEbenezer.net
(651) 251-9384
T
ttw6687
I always tried to write code so that it could be easily modified.
V
viper-2
Coding fast and coding well are not mutually exclusive.
agt
--
Freedom - no pane, all gaiGN!
Code Art Now
http://codeartnow.com
Email: (e-mail address removed)
G
gmail-unlp
Real programmers do not have these issues... but I'm not one of
them...
Fernando.
R
Robert Hairgrove
There is a variation on this (which was probably the original source)
attributed to Henry Ford (quoted from memory here):
We can deliver it:
(a) well done;
(b) in short time;
(c) cheaply.
Choose any two.
M
Michael Doubez
And of course the *code right/ path is also the *project*'s fast path
(if not the code fast path).
Saying that code fast path is project's fast path is like saying that
making a loan is a fast way to become millionaire.
This is of course to be balanced with the kind of project: if you
don't expect to live long enough to have to repay the loan that might
be the path.
Some would say it is also a bad consultant's path, but that's plain
slandering and I won't say it. No, it won't pass my lips.
[snip]
R
Richard Maine
Michael Doubez said:
It might be a difference in idiom between French and English, but I
think you mean "taking" a loan instead of "making" one. In the most
usual scenarios, it is the bank that makes a loan and you that takes
one. If I make a loan, that's like when I loaned money to my son to help
him with the down payment on his house, or when I sold a rental
appartment building and took paper for part of the sales price. (It
hadn't occured to me until just now, but it does seem slightly amusing
that I "take" paper to "make" a loan).
I mention it because I was actually briefly confused as to what you
meant. One can make money by making loans (banks do it). At first, I
tried to connect that to your statement. Only when that didn't seem to
make sense did I realize that you probably meant it the other way, which
then made plenty of sense.
R
Richard Maine
Robert Hairgrove said:
Ford might have been the originator. I wouldn't off-hand know (and
didn't bother to research). A recent NASA administrator (in)famously
adopted a variant of it as sort of a slogan. Unfortunately, he rather
missed the point. We (NASA) were going to do things "better, faster,
cheaper". Yes, we were going to do all three. As was no great surprise
to some people, insisting that we could do all thee often ended up
achieving none of them.
A
Alain Ketterlin
I know this as the "Extended Heisenberg Uncertainty Principle" (applied
to IT), saying that the feature set, cost and delay of a project cannot
be simultaneously known with high precision. Sorry, I have no
reference/source.
-- Alain.
M
Michael Doubez
Yes I meant 'taking a loan'.
In french we have to different words and the verb is not significant.
Thanks for correcting me.
[snip]
M
Michael Doubez
"Get the product working" might be the heck. And if so, you made a
loan but still have to repay de the debt off which can be expensive
(or at the detriment of customers which is what happens today).
Well, I won't debate it since the current consensus goes your way; we
could debate taking the example of Apple that delivered a good product
or discuss on how to measure the real costs of quality.
The rest is just my rambling.
This is quite a static view. In fact, one observes the process, the
"go fast" starts with a lot more feature that are removed when times
goes short, while the go right as lesser decrease but can subsequently
built on solid foundation.
Agreed, that is the usual view. Nitpick: note that in the diagram,
there is no direct branch from one to the other (which IMO should be a
singly directed edge from right to fast).
This is all the most easier since customers are now so used to having
bug and buying faulty software. Although that this is not necessarily
true on the asian market (or so I have been told), where a shoddy
product will simply be not sold by distributors.
The marvels of marketing. You are of course right on the state of the
art but I don't have to like it.
Oh and you will find that quite a few peoples became millionaire by
borrowing money to invest in higher return ventures (e.g. during the
property boom). Actually, it's probably the fastest way to become
millionaire. Borrow a large amount of money, invest it in a high risk,
high rewards venture and either go bankrupt or become millionaire
But the milionnaire repaid his debt off, didn't he ?
And I expect the successful one was the one to do it right (excepted
for the varibility due to lucky ones).
Truth is that in the software factory, you don't always have the
budget to go back and makes things right where you made them fast.
Embracing "go shoddy" as a way of coding rather than a downside of
pressure is plain wrong IMO.
J
James Kanze
And it's a false idea. In practice, taking the right path will
generally result in the product working significantly faster.
Except that taking the fast branch doesn't get you to market
faster, and often will shut you out of the market once you get
to market (since too many bugs will give you a bad reputation).
B
Balog Pal
Yannick Tremblay said:
This sounds like "leading". Yeah, you spend more time on design, design
reviews, other quality measures. No, you do not get the product later with
that approach comparing to the alternative "jump to coding" way.
The "fast way" is just delusion. Like in traffic when you chose a huge
detour on small streets avoiding traffic lights ws the highway where you sit
and wait green at some moments. That feels like waste, while otherwise you
have some speed all the time.
The projects I saw being done "the right way" were all finished much closer
to original deadlines (as a matter of fact were practically in time), and
used up considerably less overall effort. While tho others went way over
time, and tied down resources after release.
It is old established fact for software development, that good quality is
cheap, and defects are expensive.
J
James Kanze
[...]
One major qualification is definitly in order. The discussion
has been fast path vs. right path, as though it were some sort
of binary choice. In fact, of course, there are all sorts of
variations you can follow. I interpreted the earlier postings
as using "fast path" and "right path" as characterizations of
a certain type of process. If by "fast", you mean time to
market, it's often the same as "right".
But not if you've omitted features which will have to be added
(quickly) later
.No. You will see the benefit immediately, in easier testing and
validation. How do you write unit tests if you don't have
a modular architecture? And good unit tests reduce total
development time. (Up to a point, of course. But the number of
organizations which have reached that point is very, very
small.)
[...]
Yes. By definition. That's why I assumed some sort of
characterization.
B
Bart van Ingen Schenau
There is also a large market where the end-customers don't view the
product as software and for that reason are less tolerant about having
bugs in the product. One product where customers are not accepting
buggy software is the radio/entertainment system of their car.
Bart v Ingen Schenau
E
Ebenezer
I think of the tortoise and the hare. It's a paradox how
the tortoise defeats the hare. Even though the hare has
gotten far ahead of the tortoise, the tortoise has read
how the story ends and so he continues by faith.
Ploddingly yours,
Brian Wood
P
Paul
According to this diagram there is no path that leads to good code.Lynn McGuire said:
If there was a fast path leading to good code I would choose that one
L
Lynn McGuire
According to this diagram there is no path that leads to good code.
If there was a fast path leading to good code I would choose that one
Yup, that was the point. There is no path to good code.
After a software product is in a the wild for a while,
everything is a patch.
Lynn
Ö
Öö Tiib
Me too. There are some things to keep in mind when going to code fast:
1) It is often faster to write new code initially unintegrated from
rest of application. As result i do not need to build the whole
application to see if it compiles and links. I do not need to navigate
in whole application to particular place/situation to see if and how
it works.
2) It is faster to see if it compiles and how it behaves instead of
reading the code and imagining its behavior. For that purpose it is
good to write tests. Sometimes little separate unit tests are fine,
sometimes testing application can be made. Testability also indicates
how clear are requirements and how easy is to integrate the new code
with something else.
3) When i integrate my code with rest of the application then i pay
attention that it should be made cheap to throw it or its parts away
and replace with something else. New requirements *will* pop up always
(unlike comic tries to tell). If the initial design does not fit with
new requirements then it is often faster to write that part anew and
not to try and hack the previous attempt to meet new requirements.
4) GUI is terribly slow to test. It changes a lot depending on things
displayed, skins and styles and localization settings used, so
automatic test frameworks can somewhat support but not replace human
testers. Since GUI is something that share-holders see, the
requirements about it change most often. We try keeping GUI as
separate layer and never place application's business logic into GUI
layer. Then that layer can be replaced with fake "GUI" layer and usual
unit tests can be written using it.
5) The external devices and third party applications are in too
constant change ... quite like GUI and even more expensive to test. We
always aim to fake these things too, it ends up faster to market.
Some novice may think that i talk too lot about tests. Nope. Usually
more than 60% of to-market effort goes into discovering and dealing
with issues so that is the biggest part of real development and it
gives best effect to speed it up.
As for "good code" is code that my team members do understand and
accept when they read it. For achieving that we have review process.
Team members have to read each others code and then write what they
did not understand, what defects they saw and what did not fit with
coding policies that we have agreed to use. Defects discovered that
early are cheaper to fix too, so reasonable review process actually
speeds everything up and helps to achieve "good code" too.