On 14 Oct 2009, at 02:40, Thomas Petersen wrote:
[snip]
". Changing substantial chunks of business logic is not easy. In
fact, it can be prohibitively expensive."
Can you give an example?
[snip]
I've been dealing with a legacy system for $client. About 200k lines
of rather bad code. The business logic and display logic are
intertwined. No automated tests on the code side. Almost no
documentation. The business logic isn't well understood - either by
ourselves or $client since original authors on the business and the
code side no longer work for either organisation.
Improving the UX and code design of that system is a royal PITA. It's
a snake pit of side effects where one seemingly innocuous change on
one report rolls over and affects three others.
Should it have been built that way? Hell no. Could it be improved with
sufficient effort so that changes become substantially easier? Yup.
Are there processes that could have built systems of similar
complexity without these problems - certainly.
Changing for that client is going to be a long term issue. Years of
work. In the mean time changes are going to remain complex and
expensive.
Unfortunately - systems like this seem to be distressingly common in
my experience...
Sigh...
<aside>
I feel like I want to support everybody in this feisty discussion.
On one hand I find doing usability testing throughout the whole
process of developing a product amazingly useful. From sketchy paper
prototypes in the initial problem discovery / ideation stages. More
focussed paper prototyping mixed in with some XHTML prototypes (that
we can mostly take through to development later) during development.
Testing after each feature is complete so we can get feedback and
iterate and improve. Testing after release so we can verify against
real world usage. Lots of _little_ tests all of the time.
Maybe I'm just rubbish at design - but all of these find problems that
I'd have missed otherwise. They make the product better - and the
quicker I can get that feedback the cheaper the change (the saving in
not building something at all is fantastic for example :-)
On the other hand I'm in an agreement with Thomas that you get a huge
advantage by testing against the real product. Good development teams
with modern development practices are amazingly more productive and
effective than even a few years ago; producing code that's much
cheaper and simpler to change and update. I find that some people on
the design side haven't yet adapted to the speed a good development
team can change direction and implement ideas - even quite large
changes in business logic.
I'm much, _much_ more likely to build/release/test now that I'd have
been ten or fifteen years ago. With some projects I can go from idea
to an A/B test on a live site in hours - not days or weeks. Building
and testing complex hi-fi prototypes has almost completely disappeared
from my working practices because it's not cost effective or useful.
On the gripping hand I wonder how much of this argument is down to
differing product development styles and practices. I wonder if we
actually talked a bit more about some concrete examples of what we
actually did we'd find that everybody is much closer to doing the same
thing than people suspect.
</aside>
Cheers,
Adrian
--
http://quietstars.com - twitter.com/adrianh - delicious.com/adrianh
________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... [email protected]
Unsubscribe ................ http://www.ixda.org/unsubscribe
List Guidelines ............ http://www.ixda.org/guidelines
List Help .................. http://www.ixda.org/help
