If There Is Only One Solution, Get a Second Opinion
2015-08-31 11:34
459 查看

you’vE pRoBABly HEARd THiS SAid BEFoRE. If you’re an experienced architect, you know it’s true: if you can only think of one solution to a prob- lem, you’re in trouble.
Software architecture is about finding the best possible solution for a problem given any number of constraints. It is rarely possible to satisfy all requirements and constraints with the first solution that comes to mind. Generally, tradeoffs must be made by choosing the solution that best satisfies the requirements according to the most critical priorities.
If you only have one solution to the problem at hand, it means that you will have no room to negotiate these tradeoffs. It’s very possible that this one solu- tion will be insatisfactory to the stakeholders of your system. It also means that if priorities are shifted due to a changing business environment, your system may have no room to adapt to new requirements.
Rarely, if ever, is this situation caused by a real lack of options. It is much more likely due to the inexperience of the architect in this particular problem domain. If you know this is the case, do yourself a favor and ask someone more experienced to give you a hand.

A more insidious manifestation of this problem is when an architecture is designed from habit. An architect can be experienced with a single style of architecture (e.g., a three-tier, layered client-server system), but not know enough to recognize when that style doesn’t fit. If you find yourself in the situation where you automatically know the solution, without having done any comparison to other approaches, stop, take a step back, and ask yourself if you can think of another way to do it. If you can’t, you may be in need of some help.
A friend of mine was once the technical person in charge of a small, but grow- ing, Internet startup. As its user base started growing, so did the load require- ments on its system. Performance was going down the tubes, and the company was starting to lose some of its hard-won user base.
So, the boss asked him, “What can we do to improve the performance?” My friend had the answer: “Buy a bigger machine!”
“What else can we do?”
“Umm…as far as I know, that’s it.”
My friend was fired on the spot. Of course, the boss was right.
If There Is Only One Solution, Get a Second Opinion
Timothy Highyou’vE pRoBABly HEARd THiS SAid BEFoRE. If you’re an experienced architect, you know it’s true: if you can only think of one solution to a prob- lem, you’re in trouble.
Software architecture is about finding the best possible solution for a problem given any number of constraints. It is rarely possible to satisfy all requirements and constraints with the first solution that comes to mind. Generally, tradeoffs must be made by choosing the solution that best satisfies the requirements according to the most critical priorities.
If you only have one solution to the problem at hand, it means that you will have no room to negotiate these tradeoffs. It’s very possible that this one solu- tion will be insatisfactory to the stakeholders of your system. It also means that if priorities are shifted due to a changing business environment, your system may have no room to adapt to new requirements.
Rarely, if ever, is this situation caused by a real lack of options. It is much more likely due to the inexperience of the architect in this particular problem domain. If you know this is the case, do yourself a favor and ask someone more experienced to give you a hand.

A more insidious manifestation of this problem is when an architecture is designed from habit. An architect can be experienced with a single style of architecture (e.g., a three-tier, layered client-server system), but not know enough to recognize when that style doesn’t fit. If you find yourself in the situation where you automatically know the solution, without having done any comparison to other approaches, stop, take a step back, and ask yourself if you can think of another way to do it. If you can’t, you may be in need of some help.
A friend of mine was once the technical person in charge of a small, but grow- ing, Internet startup. As its user base started growing, so did the load require- ments on its system. Performance was going down the tubes, and the company was starting to lose some of its hard-won user base.
So, the boss asked him, “What can we do to improve the performance?” My friend had the answer: “Buy a bigger machine!”
“What else can we do?”
“Umm…as far as I know, that’s it.”
My friend was fired on the spot. Of course, the boss was right.
相关文章推荐
- linux之Segment Fault错误分析[2]
- linux之Segment Fault错误分析[1]
- CentOS 6.3下 安装 Mono 3.2 和Jexus 5.4
- 如何查看别人网站的访问量
- ARM9(S3C2440)时钟与定时器
- Hive Developing
- [转]CentOS 6.5安全加固及性能优化
- thinkphp 在nginx服务器上url重写失败,找不到路径
- ecshop 网站标题不更新或内容不更新
- hadoop是什么?
- hdoj 4322 Candy 【最大费用最大流】【经典题目】【最大流时 维护费用的最大效益】
- Hadoop常见错误及解决办法汇总
- Linux:chmod -R 777 * 是什么意思?
- SPOJ Optimal Marks(最小割的应用)
- linux 命令汇总
- Linux-《Linux命令行与shell脚本编程大全》阅读笔记
- ubuntu中desktop文件执行报错
- Linux系统文件描述符理解
- Linux 进程(二):进程关系及其守护进程
- LinuxUnix time时间戳的处理转换函数