I think the biggest drawback is finding good software design reviewers. If you haven't got the technical expertise to judge the work of your programmers, you're not equipped to judge the result of a software design review, or to tell apart a good consultant from a quack.
This is the textbook for the MIT course "Software Engineering for Internet Applications" ... The most concise statement of the course goal is that "The student finishes knowing how to build amazon.com by him or herself."
I intend to spend the next few months reading through this book, completing the exercises, and coming as close to the experience of that course as I can without moving to Massachusetts.
I don't really get how the he goes from the problem he describes to the solution he advocates.
He doesn't go into too much detail, but it sounds like the application in question was running on a grossly resource-starved system. If an application needs more RAM than is available, it ends up using the disk as swap space. This is a massive performance killer in my experience.
The fix here had very little to do with documentation and design review, it just involved buying a decent server.
Also, how can the developer not have noticed that the app took 5 minutes to display a page? Surely the developer actually loaded a few pages, right? Maybe it was faster in the development environment (my desktop is way more powerful than most virtual slices). When it was actually deployed the developer could easily have said "gee, this is really fucking slow, maybe we need some real hardware".
The incompetence here wasn't a lack of design docs or review, it was much more basic. At some point there was a failure of communication between customer and developer
Here's some missing bits of communication ...
C: "I'm planning to deploy to a virtual host, and I'll only have 256MB of ram, so code like it's 1999."
or ...
D: "I see that you are using a virtual host for production. Did you notice that each page takes five minutes to load? I think you need some real hardware. I can help you purchase that."
or ...
C: "Why does each page take five minutes to load? This app won't be successful unless page loads are no more than 2-3 seconds each."
"There isn't any documentation," replied the business guy who had created the idea and written the checks to the programmer
This is so vague, that it borders on absurd as a case of point. A counter could be levied by this example that many times the business sees no value in documentation, and is in a rapid cycle to get a first version out the door and is leaning on the developer to get it out the door. As a developer who is being contracted, he is familiar with the source so documentation is not critical for him to understand or maintain the system. It not until something goes wrong and the business is looking to sever their relationship with said developer, that documentation becomes important and it is always the developers fault if it is not done. If the business did not pay for documentation then they have no valid expectation that they should receive documentation.
Conversely, the developer should stress the importance of paying the developer to document the system and help them understand the pitfalls of not having the system documented. The if I get hit by a bus speech.
Mostly a case scenario when development is completely outsourced , its suggested that the tech vendor drafts a technology plan inclusive of Design & Architecture . Get the technology plan vetted by experts , plenty of tech guys would be willing to help for free. A clever way to go about it is , post a specific tech challenge / query on LinkedIn , of those answering and willing to help request if they would vet ur technology plan & get this done by 3-4 good tech Samaritans
Don’t go overboard – prepare for success not for failure , spending too much time on analyzing tech plans is preparing for failure. Focus on building the Biz & success. Once u have costumer traction all tech challenges can be solved . Heard of Twitter in the early days ?
I think the biggest drawback is finding good software design reviewers. If you haven't got the technical expertise to judge the work of your programmers, you're not equipped to judge the result of a software design review, or to tell apart a good consultant from a quack.