8/2/2019 Addendum - Using the Right People for the Right Jobs

1/1

Implications for Software RedevelopmentWarren Marshall, Software Architect of CGT Reporter

Page 1 of1

Addendum - Using the Right People for the Right Jobs

One of the biggest issues we will face in this development, whichever way we take it, is how to

channel the right people to the right development tasks.

Many of the apparently straightforward programming tasks, in a product like this one, require theprogrammer to recognise the subtle differences in meaning between almost synonymous data

items.

In theory, this should not be necessary, as every functional component of the software should be

unambiguously specified before a line of code is written. In practice this level of specification is

both unwarranted and unaffordable, unless the task is a purely technical one such as spaceship

deployment or bridge construction. So the programmers need to quickly develop some level of

business understanding about the rules they are encoding in the software, and management needs to

be constantly aware of the potential problem here.

We know that some programmers (and some programming teams) understand the subtle nuances of

a business rule better than others, or more importantly, understand that they dont understand andthus seek more information. We need to make sure that we have scoped each member of the

programming team in this regard, as quickly as possible, so we do not end up with code

components which fundamentally miss the mark and need to be corrected or redeveloped using

time we do not have.

If we are working with two or three co-dependent teams, working in different countries, the

management of comprehension failures of this type is more difficult. In our specific scenario, we

have, lets say, a team of 8 .net programmers in Malaysia, creating a new interface; while we have

a team of 3 in Boston, modifying the US product for additional Australian functionally (just two of

several dozen high-level tasks to be undertaken).

A worst-case scenario may see the Malaysians implementing windows which are hard forAustralian accountants to use or understand, and which misrepresent the meanings of data they are

trying to show, while their US counterparts fail to recognise that the Australian model for trust

taxability is slightly dissimilar to the US model, and they thus implement changes which are not

only wrong, but are subtly wrong and thus hard to recognise in testing (and costly in time and

money once finally discovered).

A best-case scenario might instead see the Malaysian team with the same task of implementing an

accountant-friendly main window, but mentored by a user, during that critical design stage, and

again after a relatively short period into the coding, to catch misunderstandings before they become

implementation failures. On the US side, a training session of the development staff, covering the

Australian securities environment and Australian presentation standards (dates, financial naming

conventions, spellings, etc.), may be all that is required to establish sufficient awareness that they

need to tread carefully.

None of this is rocket science (actually rocket science is relatively easy), but the obvious is

sometimes missed in the rush to get results. If we assume our developers are very capable but

untrained in the business of Australian securities (and Australian style), we will get better results

than if we expect them to interpret correctly based on what we assume they already know.