|
|
Posted by Carl on 10/13/05 21:48
NC,
NC wrote:
>
> 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.
If the development stage is the responsibility of the development group,
and the same applies to the sales and implementation stages/groups,
then, for the sake of this discussion the terms are interchangeable and
your clarification is not necessary. My problem is not with your exact
definition of 'sales', but rather why you think its relevant to this
discussion at all.
>
> 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].
Again, your totally off topic here. Please read the OP. This discussion
is about "developing webapplications", your observations on companies
with existing software are irrelevant, and your observations on ROI even
more so.
Additionally, i would like to ask why you would even have a sales team
if you have not developed (i.e. Development group/stage) a product?
Unless of course you are still thinking in terms of a company with an
existing product, which again, is not relevant to this discussion. You
may also want to consider that if you already have a product, the
development stage has clearly finished (you have a product, right?).
>
>
>>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.
>
OK, another misunderstanding. Generally, application development
includes the initial development, and ongoing application maintenance.
You are talking about maintenance, not development (at least not in the
context of this discussion).
Your 'existing product' is a red herring, stop confusing the issue.
>
>>>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.
Wrong. You assume that my concern is "mostly about software
architecture". Software architecture means nothing when it is not used
to address a problem; or a requirement of the specifications if that
suites you better. We are trying to discuss software design, patterns,
etc. that can be used to solve common problems, nothing more.
> 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).
Yeah, tell the project architect, designer, marketing, or the end user
for that matter that you think that their request would be better
handled by better "training or organizational changes", and you will not
implement it. HA! I am begining to think you haven't tried this in the
RealWorld(tm) yet. Either that or your requirements were terribly out of
touch with reality. But again, this has nothing to do with the topic of
the OP.
HA, I'm still laughing...training... ;)
> 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?
Another assumption. The need for compromise between good design and
usability is your own invention.
There is no reason you cannot use a well thought out design pattern,
reusable libraries, application frameworks, etc. to implement usability.
>
>
>>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 we are arguing apples an PEAR's here :)
Do not confuse the 'design' of the application (i.e. feature x, feature
y) with the design of the system (i.e. written in php, using db(x) for
storage, etc), aka the architecture, which is what this topic is about;
Implementing the feature x design (requirement) effectively through
application design (application architecture).
>
>>>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
>
Cheer,
Carl.
Navigation:
[Reply to this message]
|