

Software Design Review - tjr
http://philip.greenspun.com/software/design-review

======
mdemare
Note that Greenspun is inviting comments.

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.

------
ericlavigne
Just the fact that he links to SEIA would be enough to make this the best post
I have read all day.

<http://philip.greenspun.com/seia/>

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.

~~~
tjr
Good to hear! It's an excellent book.

------
autarch
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."

------
kls
"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.

------
TalentOnCampus
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 ?

