«

On 10 jan, 18:12, nos...@see.signature (Richard Maine) wrote:
> Michael Doubez <michael.dou...@free.fr> wrote:
> > Saying that code fast path is project's fast path is like saying that
> > making a loan is a fast way to become millionaire.
>
> It might be a difference in idiom between French and English, but I
> think you mean "taking" a loan instead of "making" one.

Yes I meant 'taking a loan'.
In french we have to different words and the verb is not significant.
Thanks for correcting me.

[snip]

--
Michael

On 11 jan, 13:01, ytrem...@nyx.net (Yannick Tremblay) wrote:
> In article <f8635f6b-b8d0-4df8-b72e-888ebf480...@e4g2000vbg.googlegroups.com>,
> Michael Doubez *<michael.dou...@free.fr> wrote:
>
>
>
> >On 10 jan, 03:52, Ebenezer <woodbria...@gmail.com> wrote:
> >> On Jan 9, 3:04 pm, "Lynn McGuire" <l...@winsim.com> wrote:
>
> >> > How to write good code:
> >> >http://xkcd.com/844/
>
> >> > I usually follow the code fast branch myself.
>
> >> > Lynn
>
> >> 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.
>
> >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
> >taking a loan is a fast way to become millionaire.
>
> Sorry Michael but the "metaphore" is broken.
>
> The idea of the code fast approach is that you get a product working
> sooner albeit arguably with more bugs or with a worse architecture.

"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.

> The code right approach is that you spent more time to get the
> architecture and design right but get the product later.
>
> The possible consequences:
>
> code fast:
> + Go to market sooner
> + Start getting revenues sooner
> + Get in before the market or requirement changes
> - Have less features
> - Maybe have more bugs
> - Maybe loose your reputation because of too much bugs
> - Future improvement more costly because of poorer architecture
>
> code right:
> + Maybe have less bugs
> + Maybe have more features
> + Have a better architecture, more modular. easier to add to
> - Start getting revenues later
> - Maybe get to the market too late (competitor took over the opportunity)
> - Maybe get overtaken by changes in requirements before release.

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.

> Both approaches have their pros and cons. *The correct answer is in
> getting the balance correct.

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.

> But as far as the loan metaphore is concerned, the sooner you go on the
> market, the less you have to borrow so I am afraid this is upside
> down.

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.

--
Michael

On Jan 11, 12:01 pm, ytrem...@nyx.net (Yannick Tremblay) wrote:
> In article <f8635f6b-b8d0-4df8-b72e-888ebf480...@e4g2000vbg.googlegroups.com>,
> Michael Doubez <michael.dou...@free.fr> wrote:
> >On 10 jan, 03:52, Ebenezer <woodbria...@gmail.com> wrote:
> >> On Jan 9, 3:04 pm, "Lynn McGuire" <l...@winsim.com> wrote:

> >> > How to write good code:
> >> >http://xkcd.com/844/

> >> > I usually follow the code fast branch myself.

> >> 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.

> >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.

> Sorry Michael but the "metaphore" is broken.

> The idea of the code fast approach is that you get a product working
> sooner albeit arguably with more bugs or with a worse architecture.

And it's a false idea. In practice, taking the right path will
generally result in the product working significantly faster.

> The code right approach is that you spent more time to get the
> architecture and design right but get the product later.

> The possible consequences:

> code fast:
> + Go to market sooner
> + Start getting revenues sooner
> + Get in before the market or requirement changes
> - Have less features
> - Maybe have more bugs
> - Maybe loose your reputation because of too much bugs
> - Future improvement more costly because of poorer architecture

> code right:
> + Maybe have less bugs
> + Maybe have more features
> + Have a better architecture, more modular. easier to add to
> - Start getting revenues later
> - Maybe get to the market too late (competitor took over the opportunity)
> - Maybe get overtaken by changes in requirements before release.

> Both approaches have their pros and cons. The correct answer is in
> getting the balance correct.

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).

--
James Kanze

"Yannick Tremblay" <>

> The code right approach is that you spent more time to get the
> architecture and design right but get the product later.

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.

On Jan 12, 10:42 am, ytrem...@nyx.net (Yannick Tremblay) wrote:
> In article <1a216568-7c9f-437b-8bd5-36522199b...@z5g2000yqb.googlegroups.com>,
> James Kanze <james.ka...@gmail.com> wrote:

[...]
> >> The idea of the code fast approach is that you get
> >> a product working sooner albeit arguably with more bugs or
> >> with a worse architecture.

> >And it's a false idea. In practice, taking the right path
> >will generally result in the product working significantly
> >faster.

> I am sorry but I will have to qualify my remark and issue a partial
> disagreement.

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".

> In the code fast approach, there are a few things that you can
> sacrifice:

> 1- Quality: this result in more bugs is is almost always a bad
> thing. This should be avoided.

> It seems that all the proponents of the "code right" approach assume
> that only quality can be sacrificed. This is not the case. It is
> perfectly possible to have a fast approach that does not sacrifice
> quality.

> 2- Features: as long as you have the main required features and have
> the quality, your product will sell. There's a lot of fluff features
> that are not necessary to make a good product that sell well.
> Cuttingdown on less important featur is likely to reuslt in hitting
> the market sooner and with less bugs. (Would the iPhone have been more
> successful if Apple had waited to implement multitasking and MMS
> before releasing it? )

> 3- A clean modular reusable architecture that is ideal for the
> future. This can be sacrificed depending on circumstances.

But not if you've omitted features which will have to be added
(quickly) later.

> You will only see benefit of a modular architecture by having future
> improvement of the product be easier.

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.)

[...]
> If we want to go semantic, we could argue that "code right" is always
> the right thing to do since by definition is it "right" and take the
> assumption that the "code fast" branch actually means "code too fast"
> which is of course always the wrong thing.

Yes. By definition. That's why I assumed some sort of
characterization.

--
James Kanze

On Jan 11, 3:27*pm, Michael Doubez <michael.dou...@free.fr> wrote:
> On 11 jan, 13:01, ytrem...@nyx.net (Yannick Tremblay) wrote:
> > Both approaches have their pros and cons. *The correct answer is in
> > getting the balance correct.
>
> 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.

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.

>
>
> --
> Michael

Bart v Ingen Schenau

On Jan 12, 5:45*am, James Kanze <james.ka...@gmail.com> wrote:
> On Jan 12, 10:42 am, ytrem...@nyx.net (Yannick Tremblay) wrote:
>
> > In article <1a216568-7c9f-437b-8bd5-36522199b...@z5g2000yqb.googlegroups.com>,
> > James Kanze *<james.ka...@gmail.com> wrote:
>
> * * [...]
>
> > >> The idea of the code fast approach is that you get
> > >> a product working sooner albeit arguably with more bugs or
> > >> with a worse architecture.
> > >And it's a false idea. *In practice, taking the right path
> > >will generally result in the product working significantly
> > >faster.
> > I am sorry but I will have to qualify my remark and issue a partial
> > disagreement.
>
> 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".
>
>

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

"Lynn McGuire" <> wrote in message
news:igd7sc$s6e$...
> How to write good code:
> http://xkcd.com/844/
>
> I usually follow the code fast branch myself.
>
> Lynn
>
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

On 1/13/2011 4:00 PM, Paul wrote:
>
> "Lynn McGuire" <> wrote in message news:igd7sc$s6e$...
>> How to write good code:
>> http://xkcd.com/844/
>>
>> I usually follow the code fast branch myself.
>>
>> Lynn
>>
> 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

On Jan 9, 11:04*pm, "Lynn McGuire" <l...@winsim.com> wrote:
> How to write good code:
> * *http://xkcd.com/844/
>
> I usually follow the code fast branch myself.

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.