|
|
|
|
|
by heavypixels
584 days ago
|
|
Those approaches do work with programming, but they don't make use of what makes programming different from other disciplines. Software is usually quick to write, update and deploy. And errors usually have pretty low impact. Sure, your website may be down for a day and people will get grumpy, but you can hack together a quick fix and have it online with the push of a button. Compare that to, say, electrical engineering, where there's often a long time between finishing a design and getting a manufactured prototype (let alone mass production.) And a fault could mean damage to equipment (or people) and the cost of having to replace everything. So you'll find that there's a lot more work done up-front and the general way of working tends to be more cautious. There's also the idea of best practices as a form of communication. This also helps for programmers, as code that looks and acts the way you expect it is easier to follow. But code is primarily shared with other programmers. Other engineering disciplines (more) frequently need to collaborate with people from other domains. For example, a civil engineer's work could be shared with architects, government bureaucrats and construction managers, and best practices often provide a common familiar standard. Compared to other engineering disciplines, software is a big unorganized mess. But it's also incredibly fast and cheap to make because of that. |
|
It is just that high-velocity low-reliability web and consumer application development is a very large niche. A lot of our best-practices are about attempting to maintain high velocity (often with questionable results), more than increasing reliability.