|
PureBytes Links
Trading Reference Links
|
Unfortunately, many software companies try to emulate Microshaft in more ways
than one.
In a message dated 6/3/99 7:54:47 PM Pacific Daylight Time,
grisham@xxxxxxxxxxx writes:
> There's always the old adage among software developers about
> their management: There is never time to do it right, but
> there is always time (and 10x-100x money) to do it over.
>
> There is another more lengthy answer. This one is written
> specifically about Microsoft, but it is not particularly
> unusual in my experience with commercial software development
> companies. Here is an excerpt from a Usenet newsgroup, passed
> along to me by a friend some weeks ago. It is food for thought
> and maybe answers part of your question.
>
>
>
> You may have wondered why Microsoft products are so bad, and
> why they don't seem to have a coherent design. I may have
> found an answer to this riddle in a column by Larry Constantine
> (remember him? Structured Design?) The following is a quote
> from his column in Software Development Magazine.
>
> [begin quote]
>
> In their book, Cusumano and Selby quote Bill Gates himself
> as saying, "There's no 'design,' in the sense of how the code
> works, that's never done in program management." Another manager
> explained that Microsoft uses little or no design documentation:
> "A developer's job is to write code that we sell, not to spend
> time writing high-level design documents." And Gates confirms
> this, rejecting any "methodology where you have a document that's
> independent from the source code... Going off and spending a
> lot of time on that - that's ridiculous... One document. One.
> It's the source code."
>
> [and later on in the column]
>
> In my [Constantine's] opinion, however, Microsoft has been so
> successful largely because it has been in the right places at the
> right times and ruthlessly and relentlessly pursued advantage,
> not because it produces great software and certainly not because
> it exemplifies best practices. Microsoft is about selling code
> more than it is about writing code, and there is no argument that
> it does a good job of selling. Hiring people to write code to
> sell is, of course, not necessarily the same as hiring people to
> design and build durable, usable, dependable software.
>
> Spending time designing and documenting design is "ridiculous" only
> if you don't count the time wasted later trying to work around all
> the mistakes in partitioning the problem or fixing the thousands
> of bugs that you might have avoided by first planning how things
> would fit together. It is time wasted only if you don't account
> for the thousands of hours your customers waste due to lost
> work or applications that freeze several times a day. If what
> you are selling is code, not solutions, only the code counts.
> If what you are measuring and interested in is quick answers to
> coding questions, then the coders who crank out the most lines of
> code by going directly from concept to code are the ones you want.
>
> [end quote]
>
>
>
> Just my $0.02 as a former software development manager.
>
> Rod
>
|