Is the process of design slow?

Question

I'm working on a project where a bunch of software (C++/OO) is being ported to a new hardware environment. A certain percentage of the software modules should be subjectively similar on the new hardware platform.

A code review for some of these modules has shown that the port done is been done with a minimal effort or insight - the developers doing the work are inexperienced, as often happens with porting. However it has also shown that the design of the software is lacking - either over-complicated, handles error conditions badly or just has a bunch of 'code smells'.

I have asked that instead of reviewing code after the port has been 'done', we review the design first. However, I am told that this might not be a good use of time, probably because the existing documented designs are not up to date.

Am I barking up the wrong tree? Is a design process inherently slow? Is there a way to avoid getting bogged down in the full design process. Or is hands on code always the best way to sort things out - even with inexperienced coders?

Update. Thanks for the answers so far. Yes the s/w will be used in many (hopefully) future products/revisions. Also I didn't mention that the code is going to be multi-threaded too (previously a single threaded environment). This alone maybe good enough to indicate "review the design" I would like to proactively (yuck) see if a process of design review can be put into porting. I'm distrustful of just hoping to fix something up when it stops working - if something is found in testing to be fundamentally broken I'd rather not redesign come defect fixing time.

Answer 1

I believe that if you're porting app A from hw X to hw Y, then port A from X to Y. Who will benefit from a re-design? I mean, if A does not change in functionality, then what will the business in question gain from your re-desing?

Answer 2

There has to a business benefit to the redesign, and by business benefit I mean "this redesign will reduce our time to market significantly in future releases". Are you going to be porting this code elsewhere in the future? Will you be making future releases with significant new features? If so then it sounds like there's definitely a case to be made for at least investigating a redesign.

Or, is the project mostly in maintenance mode with no new development scheduled? In my experience, re-architecting/redesigning code in this state is usually just a developer exercise and provides no tangible business benefit to the organization.

Answer 3

Get it ported, make sure test coverage is good, and consider refactoring/re-design once you have a fully working, well-tested app on the new platform.

Answer 4

Sounds like a redesign would be a good idea, if for nothing else than to separate the h/w dependent parts from the rest. At least then your next port could focus on only those parts that really needed to change