In 1991, I designed an open platform for (soft) real-time data acquisition, online processing and visualization of physiological data, initially targeted for gastroenterology, and later extended to cardiology and so on.
The system, written in C++ with small portions in assembly, had to run under Windows 3.0 (and was later upgraded to follow the OS evolutions), and the minimum suggested hardware was a 386sx at 16 MHz. Besides doing most of the design, I also coded a large portion of the application.
I had to find a good balance between good object-oriented design and performance. Extendibility was a must - the whole idea of an open platform was that we could plug in new drivers, new real-time algorithms, new kind of visualization. Performance was also critical, and given the non-preemptive nature of Windows 3.x, a good deal of effort went into making everything fast and non-blocking. In the beginning, I even used self-modifying code in some critical points to squeeze a few clock cycles, and abused :-) of a few undocumented APIs. In the end, I brought into the company an higher awareness of what made a good hardware for Windows, they redesigned their flagship hardware to radically improve performances, and we could remove a few tricky portions here and there.
The company (Synectics Medical AB, Stockholm) at a point merged with Dantec Technologies, and was later bought by Medtronics. After all those years, that system is still sold! An unofficial source told me that after I left the company, they tried to design a newer, more abstract version of the system, but didn't succeed: performance wasn't good enough. Software design is about finding balance between many forces. Ignoring performance in a performance-critical systems is simply not good, as it is ignoring reusability, extendibility, maintainability, and so on. As usual, finding balance is harder than optimizing for just one property.
Several years later, I started working for an Italian company, a well-known leader in fitness equipments. My experience with medical systems certainly helped my learning their domain quickly (you can't design a good system without an appropriate understanding of the problem domain). Now we are designing a system which is very close to the medical field, and to the kind of applications I developed in that field.
Many things are different, however. Sampling rate is much smaller. Computers (CPU, RAM speed and amount, graphic cards, etc) are enormously more powerful. We still need some kind of extendibility, but on a different scale. We can afford to buy components that I had to hand-optimize. We can afford to use XML descriptors, interpreted at run-time, where I had to create custom drivers in C++ or even in assembly. The overall application is also less ambitious, so we can certainly benefit from a scaled-down architecture. Scheduling is also more compressed in these days than it was 14 years ago. In fact, planning is now becoming more important than it used to be, exactly because we have shorter schedules. Where many people find activities like planning and design as time-wasters, I see them as time-savers. Assuming, of course, that we take the time to learn how to plan and how to design. Unfortunately, too many software professionals don't take that time, and then pretend coding it's all that matters.