Best Practices to Manage Complexity in Hardward/Software Design?

Whatever works for you is good. Writing stubs may be worth the effort, bur not writing stubs is less effort.

I try to start with interfaces and data structures, and to write small testable pieces that instantiate or use them. Every piece incorporated into a larger structure has already been vetted, and unless I've made a false start, nothing is discarded.

Jerry

Is there any other reason besides "to support unit testing" to implement from the bottom up? I was wondering if the people that have problems with TDD might be the people that are used to implementing form the top down.

I have always coded from the top down. I make a user interface, then start figuring out how what is needed to support the user interface. I add stub classes with comments like "UNDONE" or "TODO". When I can search my entire project and I don't find any of these comments, then I'm done. Of course this method has made adopting TDD very diffucult for me.

Does anyone else prefer top down to bottom up development? and has that hindered your adoption of TDD?

Do you find that this impairs your ability to apply unit tests, specifically as TDD?

-Scott Frye

Yep. Top down design often produces a module split which looks great at first sight, but doesn't play out too well in practice. It might be clumsy to implement, or it might produce inefficient results. Also top down often produces a split which doesn't match well with existing code, and inhibits reuse of that code. Implementing bottom up makes you aware of these issues at an early stage, while reworking the top down design is still a fairly lightweight task.

Regards, Steve

I'd like to illuminate that with an example. One project needed to control a bunch of switches, implemented as bit-I/O . The top-down plan called for the functions (in C usage) on(), off(), and toggle(). It was known at planning time that actual outputs would be word wide. The bottom-up design immediately turned up a snag. The I/O device's state couldn't be read, so an image of its state would need to be kept in memory. With the switch bank serving several tasks, that might have necessitated the inclusion of an otherwise unneeded semaphore system. Discovering that late in a top-down implementation would have meant a lot of code rework. (That's all subjunctive because I built hardware to avoid the problem. The freedom to do that isn't always to be had.)

Jerry

As with most approaches to any problem, the appropriate method should be used. Properly mixing the top-down and bottom-up methods to your needs. Some problems are best solved by building up a solution, others by decomposing or structuring the proposed solution, a few rare instances may even need a middle-out approach if your existing solution base is the inside (not top or bottom) for the final solution. Refactoring, reworking, or whatever is always available to revise an appropriate solution. Use the techniques that best fit your needs and design approach.

David

If you built the hardware to avoid the problem after it was discovered then it's evidence to support bottom-up implementation -- because the problem would not have been discovered at the bottom of the software to be fixed at an even lower level.