How_to_build_great_software by georgetitan

VIEWS: 0 PAGES: 3

									Title:
How to build great software

Word Count:
723

Summary:
In this article I'm going to explain the top 10 software development
fallacies my company avoids. By avoiding these myths and concentrating on
excellence, we are able to make great quality software.


Keywords:
software, myths, great, fallacies, development


Article Body:
In this article I'm going to explain the top 10 software development
fallacies my company avoids. By avoiding these myths and concentrating on
excellence, we are able to make great quality software.

Myth 1) Software must be designed in detail before development starts, so
that a clear plan can be out-layed.

The truth) The more complex a design, the more like software the design
itself is. By perfecting a design, then writing the software to that
design, you're effectively writing the work twice. Instead, by doing just
some simple design sketches and data modelling rather than a book-like
design, a good development team can create a shell for the software and
efficiently refine it towards the finished product. This process of
refinement creates natural prototypes, allows easy adaptation when issues
that would be unforseen by a design arise (or brought up as fresh
concerns by a client), and the total process takes significantly less
time. To pull this off requires a close team, skill, and experience, but
it is by far the best option for the majority of situations.

Myth 2) There are programmers, designers, analysts, and users.

The truth) By structuring development so that all developers get some
exposure to each part of the development process, skills may be shared
and greater insight may be gained. If developers are encouraged to
actually use the software then they can use that expertise to think of
improvements that otherwise would not come to light.

Myth 3) A happy team is a productive team.

The truth) A team of people with a wide variety of natural skills,
experience and concern, that criticises each other and argues vehemently
over the smallest details, will bring up and resolve issues that
otherwise would never be tackled. A furnace of relentless argument is the
best way to forge understanding and reach perfection.

Myth 4) It's important we understand our direction and don't compromise
with it.
The truth) Life is compromise, and compromise is not a weakness. There
will always be issues (such as efficiency, budget, ease-of-use, power,
scope, and the need for easy internationalisation) that cannot be
simultaneously met without such compromise.

Myth 5) We know what the client wants, we know what the issues are.

The truth) Without constant re-evaluation, it is easy to lose track of
the objective. Developers are often faced with problems to solve that
they consider the issues, when those are in fact separated from the
actual market goals and can become totally irrelevant. Developers must
always understand the market goals and be able to adapt when other things
change, or even the goals themselves change.

Myth 6) Bigger is better. Features are cool.

The truth) Features can easily confuse users, and their actual value
should always be considered against the cost of confusion. In some cases
it is sensible to actually remove working features due to such concerns.

Myth 7a) The customer is always right.

The truth) Most customers try hard not to look ignorant   in front of
software developers, and hence phrase their suggestions   in a technical
way. The effect is that often suggestions aren't really   appropriate,
because they're not founded on a solid understanding of   technical issues.

Myth 7b) The customer is often wrong.

The truth) Although customers needs are often not best met by doing
literally what they say, they always know what they want and why they
want it - and usually for very good reason. Understand them and adapt
what they say, discuss with them, but never ignore them.

Myth 8) Comment your code a lot.

The truth) Good code needs hardly any commenting, because sensible uses
of naming and white-space are better alternatives. Comments should only
ever explain the non-obvious, or provide standard API documentation.

Myth 9) Such and such is needed, such and such is great.

The truth) A bad workman blames his tools. Whilst some development tools
aid development substantially, a good developer can do great results in
most things served to them. There are a few exceptions, like Microsoft
Access, or assembly language, but generally speaking the difference in
quality results is much more due to the skills of the developers than the
quality of their tools.

Myth 10) The customer will understand if there's an efficient and easy-
to-use interface.
The truth) The interface doesn't just need to be easy-to-use, it needs to
be navigatable without an overall systems understanding. Screens need to
be self-describing.

								
To top