| > if you can't do it on paper first, you're not ready to computerize the problem One of the first things I do when on-boarding engineers to our business is to walk through the entire flow on paper, in terms of assets, people, and handshakes (as if there were no computers involved). The industry my company's in is old enough that our competitors actually used to process everything with pen, paper, and stamps. technology made everything faster, but the water flows through the same pipes, so to speak. Our programs are an incomplete and evolving map of a real-world transaction-territory, and it sometimes takes people a while to grok that. Once engineers do, they gain the ability to predict behavior in un-mapped territory. Having this ability saves everyone an immeasurable quantity of time. I guess the most important takeaway, is that one must have distinct mental maps of the business process and of the program implementing the business process. This obviously varies a lot depending on the technology you're building. Although, I guess even something as abstract as `malloc` can be analyzed in this way (a map for the program, and a map for the idea of the program: allocating memory). |