2008-09-14 關於架構
Many years ago, there was a chance to work with one talented firmware engineer who were working for one of our customer. Somebody told me this guy was excellent at his job, that is, he had got good records for years, though he was still a young one. The interesting point was he always would start his job, mainly firmware coding, right after project kicked off. And he could make it at a very fast speed to meet those always tough schedule. So everybody would like to have him in project. One the contrary, there was another style. Engineer would not start coding at the beginning. He would investigate the problem, studying, specification..... But everybody, managers especially, could not wait for something realized by today, so they would think this guy was too formal and slow and keep skeptical about the outcome.
This is interesting to me about the way engineer solves problems. Though, the 1st engineer seemed to be having better EQ, I would like to remove those factor in this discussion. In general, engineer is expected to realize, implement something working. Someone would like to make some small gears at the very beginning while only a foggy idea about the final outcome, see how well it run, then modify and try again. This process will continue until whole stuff running and it seems to be reansonable for a seansoned talent. We call this is a bottom up approach. The other way, top down apporach, engineer would clarify requirement, constraint at first stage, then investigate an feasible architecture before making something realized.
I would not say which one is best, but from my experience and observantion I would like to prefer top down mixed with bottom up. Of course, it depends on case, simple tiny or complex huge one. However, I am use to think while organizing and writing something down to certain detail that I can have clear and structured image in my mind during the implementation stage afterwards. For those which are no doubt at the very beginging, we can start to make, i.e., bottom up, that concurrent development is possible. In this way, the risk to rebuild some blocks totally while integration can be mitigated. The worst case is to discard everything at some later stage. It will cause timing and resource wasted and schedule crashed.
Architecture will show its power whenever we need to know how well the product will run and how we interface other components in a big team. Moreover, in electronic product design today, we are concerning very much about design platform and reuse. It is impossible to fulfill those requirement without clear concept of architecture. Furthermore, good architecture will help in the future when we have to make some changes or when we have to fix problems, then dirty patches around the design, which eventually nobody will understand, can be avoided.
Back to real world, no company affords so-called architecture engineer, here in TW, every engineer in the team are expected to do everything as soon as possible. In reality, the winner is who can deliver the lowest price product at first time when customers with order in hand are standing in front of door today. In such situation, engineers are squeezed to get the orders. Moreover, the shorter the product life time, the worse this situation is. This is stressful to engineer and management, since we only earn shear margin after really hard working which engineer didn't get growth. And this cycle will repeat itslef for next case until finally enginner team burn out phased out, then we recruit another new team. This is really a tragical cycle.
The problem is how we save us from this kind of cycle! Improvement of the engineer productivity and quailty always help but you need to invest resource and time. No free lunch! However, enginner has to be aware of his or her situation and be willing to make change before such improvment could take effect.
