Isaac Gouy
Posts: 527
Nickname: igouy
Registered: Jul, 2003
|
|
Messiah
|
Posted: Oct 25, 2006 9:09 AM
|
|
> >> However I agree that references to Händel's Messiah or
> > other artistic enterprises don't really further our
> > understanding of software or software projects.
>
> To the contrary, I'd argue that observing the habits of
> any highly productive person can benefit developers and
> software projects. In these specific examples, several
> observations are relevant to software projects:
>
> * Both composers got paid for results, not for the number
> of hours spent or a fixed salary.
>
> * They had to meet non-negotiable deadlines.
>
> * Their work was ultimately judged by their "users"
> (audience), not by their peers. Thus, they had to be
> concerned about the UI the most (the effects the work
> would create on the audience), and not so much about the
> techniques or tools to achieve those effects.
>
> * They had to choose techniques and tools with execution
> in mind: The performers had to be able to easily execute
> what the score instructed them to do, i.e., they had to
> use familiar techniques.
>
> * In these examples, they did not aim to break new ground,
> but rather to meet the objectives of (a) pleasing their
> "users", and (b) meeting their deadlines. Instead of
> re-inventing the wheel, they re-used much earlier
> material, and stayed within the confines of well-known
> frameworks.
>
> * While they followed conventional frameworks, they added
> flourish and originality at certain places to improve
> "usability" (to please their audience).
>
>
> These are just a few observations in this context, and the
> way it applies to developers and architects are rather
> common-place restatements of what has already been said so
> many times and in so many books and blogs:
>
> * If you project's success is judged by how pleased users
> are with it, focus on usability, and don't worry about
> what techniques or frameworks to use to achieve those
> effects.
>
> * If you want to complete your project in time, don't
> break new ground, but simply imitate what has worked in
> the past, step-by-step. Follow a well-oiled formula, i.e.,
> use a framework.
>
> * Add your individual touch or innovation in well-chosen
> spots, and only to improve usability (to please users).
>
> * When you architect something, keep in mind how easy
> implementation is for developers. Choose a solution that's
> easier to implement over one that's more novel.
>
> Again, these notions have been rehashed time and again.
You're forcing trite generalizations from your pre-conceived notions about software development back onto a different context.
|
|
Previous Topic
