Re: how to write good code
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