3 ms·
Its much easier to justify changes in software requirements vs changes in hardware requirements because the perceived cost of adding a few more features on your
by pratik661 13y ago
Its much easier to justify changes in software requirements vs changes in hardware requirements because the perceived cost of adding a few more features on your application is low. Compare that to say.. adding another register to your chip..which might add millions to the whole production process. The changes can be made while the app is live. You can not do that for hardware.
- analog31 13y agoI've seen the opposite, where the effort and bureaucracy to change the software is so prohibitive that changes are made to electronics or even mechanics to avoid a software change.
- gnarbarian 13y agohe's talking about in the middle of a project. Not some giant legacy software system written in cobol running on a 30 year old mainframe where all original developers are dead and no original source code or documentation exists.
- finnw 13y ago> ... to avoid a software change. "It's OK, it doesn't need any code changes, just a modification to the configuration files, so the approval process does not apply." That company's developers just need to learn the trick of making the configuration file format Turing-complete. If you don't have time to write your own interpreter, XSLT is an easy one to sneak by PHBs. I've seen one system where 70-80% of the functionality was implemented in XSLT for this reason. It meant changes could be delivered in 5 days instead of 35. Obviously good news for the customer. The PHBs were pleased that the bug count in the C++ core had dropped (it hadn't really, we just stopped using the buggy modules.) The integration testers were pleased that the end product worked. Basically everyone was happy except the C++ reviewers in QA.
- analog31 13y agoBeautiful, Greenspun's Tenth Rule comes to the hardware department!