Posted by NC on 10/13/05 02:12

Carl wrote:
> NC wrote:
> > Nikolas Hagelstein wrote:
> >
> > > i spend a lot of time on thinking and researching about
> > > how to make developing webapplications with php a more
> > > structured/systematic thing.
> >
> > Why stop at development? Or, rather, why start in development?
> > Structure and system should be first introduced in sales and
> > implementation...
>
> In not really sure that I understand what you are trying to argue
> here, but I would argue that 'Sales' is not necessarily a factor
> that needs to be considered in the context of this discussion,
> and implementation is only one part of the development process.

I guess I wasn't clear... When I say "development", "sales",
or "implementation", I mean not development/deployment stages,
but groups of people within an organization who perform these
functions.

Most software organizations out there already have at least
one product, so whatever happens to development from now on is
a long-term issue of little immediate importance. The shorter
term issue, with much more urgency to it, is how to maximize
return on investment that has already been made in developing
the product. This is why I think that structure and system
should be first introduced in sales [team] and implementation
[team], because in great many cases it is already too late to
introduce them in the development [team].

> Structure and system _should_ be 'introduced' (at the minimum)
> well before implementation .

In a perfect world, yes. In the real world, it is often too late
for that; the product has already been released or is getting
close to it. So quite often your best bet is to introduce best
practices on the "business side" (sales team, implementation team,
support team, etc.) first and then implant them into development
of the next major release or perhaps even the next product.

> > I respectfully disgree. No matter how professional your
> > development is, your success will NOT be determined by the
> > quality of development. Whether or not your product uses MVC
> > (or another fashionable development technique) is of no
> > consequence to the buyer. The buyer wants to see the relevant
> > feature set (which is a design issue, ultimately rooted in
> > marketing), reasonable cost of ownership (which a purely
> > marketing issue), knowledgeable sales people and responsive
> > implementation people (which are human resources issues).
>
> Again, you lost me.
....
> Although you may /sometimes/ be correct in that 'success will
> NOT be determined by the quality of development', you definition
> of success and mine clearly differ. Proper design markedly
> increases _your_ ability to work with, repair, modify and reuse
> code in the future

Well, it appears that my definition of design also differs from
yours. :) Seriously, though, we seem to be concerned about
different aspects of design. To you, design appears to be mostly
about software architecture; I tend to focus on usability and
relevance to the end user's needs. Obviously, each approach has
its drawbacks. If you follow my suggestions to the extreme, you
may find yourself trying to address a need that cannot be addressed
with present-day technology (or perhaps, should be addressed by
means other than technology, such as training or organizational
changes). If I follow your suggestions to the extreme, I may end
up with a beautifully designed, but totally irrelevant to the
user's needs (and thus unsellable), piece of software... The
question is, which of the two diseases (pampering the user or
ignoring him) tends to strike more often?

> Regarding your comment that there exists a design issue is
> "ultimately rooted in marketing" has me perplexed.

Why? In your very next sentence, you agree with me:

> The issue with design is implementing the feature set
> determined by marketing,

This is exactly what I meant. Marketing suggests WHAT
should be implemented, designers decide HOW it should be
implemented. Somewhere in-between, there probably should
be a manager type who decides WHETHER and WHEN (given time
and cost considerations) a particular feature should be
implemented...

> > I think it's called PEAR; it includes code repository
> > (complete with dependency checks and defect tracking)
> > and coding guidelines...
>
> PEAR is indeed one possible answer to the OP's question,

Ah, we are not so different after all... :)

> though I think it is far from a complete solution.

But then, is any solution ever complete? :) Again, what
I like about PEAR is that it (1) offers coding guidelines,
(2) stores cataloged and (usually) documented code, and
(3) has a defect tracking system. Thus, I believe that
PEAR can be viewed as a working prototype for a company-
wide code management system...

Cheers,
NC

[Back to original message]