How To Build Great Software

How To Build Great Software



How to​ build great software
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.




You Might Also Like:




No comments:

Powered by Blogger.