Am 19.08.2011 16:02, schrieb Invisible:




>


>


Well, I expect it is, generally speaking.

Question is actually, does the added quality also give /me/ enough added 
value to warrant the price?

For some people the mere expensiveness might be worth it. ("Look, he's 
got a maddeningly expensive watch; he must be good with money, so let's 
heed his financial advice.") I don't think that's me though.

> (I still remember going into a suit shop. They have multiple racks of
> identical black suits. I pick up one that looks roughly my size. "Ah
> yes, an excellent choice, sir" the man says. I wonder, is there a suit I
> could have picked up that was /not/ an excellent choice?)

"No, sir. All our suits are expensive enough that we make money with any 
one; as long as you choose to buy, that's an excellent choice."

Post a reply to this message

On 8/19/2011 7:02, Invisible wrote:
> Then again, there are people who want to sell you a watch for £8,0
00.

That's not a watch. That's jewelry that happens to have a clock built in.
 
And yes, the people selling it tell you this. "The average kitchen has ei
ght 
clocks in it. We sell jewelry and home decor."

> I wonder, is there a suit I could have
> picked up that was /not/ an excellent choice?)

Probably not in a suit store. In wal-mart? Most certainly.

>> The REAL problem, as I see it, is the pig-headed unwillingness of so m
any
>> corporate executives to employ people who actually KNOW whether $4,000
.00
>> software or $4,000,000.00 software is needed and allow them to make th
e
>> purchase
>> decisions.

Yes. Amazing how many body shops are out there for web stuff compared to 

(say) automobile design. I guess if your business isn't primarily done ov
er 
the web, you hire a web designer, just like you'd hire a plumber to fix t
he 
pipes in your building. But if your business is internet-based, it's sill
y 
not to have that expertise working in your own best interest.

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message

Am 19.08.2011 17:19, schrieb Darren New:
> On 8/19/2011 1:34, Invisible wrote:
>> From time to time, somebody builds something that's truly
>> ground-breaking.
>> The world's tallest building, perhaps. Or the longest bridge. Or
>> whatever.
>
> Even the world's tallest building is essentially the same story, using
> the same structural characteristics, repeated 200 times.

Most bloody likely not.

The lower floors need to be as strong as possible so they can carry the 
weight of the whole tower. The upper floors need to be as light as 
possible so they can all be carried by the lower floors.

But yes, it might be the same basic design with some parameters varying. 
Plus a few special floors in between (for instance a shopping mall 
halfway up the tower).

Then again, modifying the design for a different number of floors takes 
more effort than just adding more floors at the bottom of the stack. 
Wind speed, resonances and other dynamic stuff has to be taken into 
account on a whole-building basis.

Post a reply to this message

On 19/08/2011 04:19 PM, Darren New wrote:
> On 8/19/2011 1:34, Invisible wrote:
>> From time to time, somebody builds something that's truly
>> ground-breaking.
>> The world's tallest building, perhaps. Or the longest bridge. Or
>> whatever.
>
> Even the world's tallest building is essentially the same story, using
> the same structural characteristics, repeated 200 times.

I think you underestimate the challenges. It's not like you can take a 
200 story building and just add 200 more stories. It would collapse. You 
have to come up with clever solutions for weight distribution, 
withstanding high winds, earthquakes, sunamis, make sure that water and 
power distribution works right, etc.

The first buildings with complex curves were a major feat of 
engineering. Even today, people design buildings which appear to defy 
gravity (but obviously don't).

>> And while no two pieces of software are /exactly/ alike, lots of them are
>> extremely damned similar.
>
> Sadly so. But it's an ongoing task to factor that similarity out.

Ongoing and remarkably unsuccessful, oddly enough.

>> How many compilers are there?
>
> Sure. But how many now all compile down to CIL or JVM, eliminating half
> of the work of implementing the compiler by clever reuse of code?

Yes, because tokenising and parsing the input doesn't count as "writing 
a program", does it...

> Programmers don't always succeed in not reusing code. But they strive to
> do so.

LOL.

> Also, you're looking at it wrong again. How many times does the
> Microsoft C# compiler get reused? How many times does the plumbing from
> the 23rd floor of the Empire state building get reused?

A better analogy might be "How many times does the Microsoft C# compiler 
get used? How many times does a JCB digger get used?"

Post a reply to this message

On 8/19/2011 8:33, clipka wrote:
> Most bloody likely not.

*Essentially*.  Of course all the floors aren't built quite the same, but 
they're all variations on the theme. They're each a mostly a subroutine 
invoked with varying parameters, rather than being designed from scratch 
each time.

Or, put it another way: You build a housing development with 400 homes. How 
many of those do you build from scratch, vs how many do you effortlessly 
copy after you've built the first one?

There's an *essential* complexity to software that you don't get from 
hardware, because there's no such thing as a subroutine outside of the world 
of information.

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message

Am 19.08.2011 17:45, schrieb Darren New:
> On 8/19/2011 8:33, clipka wrote:
>> Most bloody likely not.
>
> *Essentially*. Of course all the floors aren't built quite the same, but
> they're all variations on the theme. They're each a mostly a subroutine
> invoked with varying parameters, rather than being designed from scratch
> each time.
>
> Or, put it another way: You build a housing development with 400 homes.
> How many of those do you build from scratch, vs how many do you
> effortlessly copy after you've built the first one?
>
> There's an *essential* complexity to software that you don't get from
> hardware, because there's no such thing as a subroutine outside of the
> world of information.

It makes more sense to think of a piece of Software as a mold, or a 
blueprint.

In that sense, you can compare subroutines to parts (or, more precisely, 
part types); for instance, a mechanical device optimized for 
maintainability would use just one or two types of screws everywhere. 
And the crew aboard spacecraft Apollo 13 would have had one problem less 
if the Command Module and Lunar Module would have used the same 
"subroutine" (i.e. same design) for the CO2 filters, but for some reason 
the "functionality" was "implemented" twice, using different "interfaces".

Post a reply to this message

On 8/19/2011 9:40, clipka wrote:
> It makes more sense to think of a piece of Software as a mold, or a blueprint.

Exactly. Software is 100% design. Once you have determined *exactly* what 
you want to build, you're already done. :-)

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message

Am 19.08.2011 19:22, schrieb Darren New:
> On 8/19/2011 9:40, clipka wrote:
>> It makes more sense to think of a piece of Software as a mold, or a
>> blueprint.
>
> Exactly. Software is 100% design. Once you have determined *exactly*
> what you want to build, you're already done. :-)

Well, not precisely - you still have to translate the design of what you 
want to build into a computer-palatable language. And it so happens that 
often you find out during this phase that you weren't clear about what 
*exactly* you wanted to build.

That aside, IT as a whole is about much more than just design; once you 
have the software, you need to test it, install it, teach people to use 
it, and other less exciting stuff. Sometimes business people forget 
about these things. It's like they pay an architect to design a new 
building for them, but forget the budget to actually build that thing 
(let alone to move from the old building to the new one).

But hey, they also seem to forget about all this stuff when it comes to 
company mergers. Yeah, sure, in the long run you may indeed get "synergy 
effects", but until then you're in for a lot of organizational overhead 
minimizing your productivity. And once you're breaking even you're 
possibly doing the next merger already.

Post a reply to this message

On 8/19/2011 15:05, clipka wrote:
> Well, not precisely - you still have to translate the design of what you
> want to build into a computer-palatable language. And it so happens that
> often you find out during this phase that you weren't clear about what
> *exactly* you wanted to build.

That's part of being sufficiently exact. If you're sufficiently exact, the 
translation step can be automated. (For example, we call that "a compiler". ;-)

> That aside, IT as a whole is about much more than just design; once you have
> the software, you need to test it, install it, teach people to use it, and
> other less exciting stuff.

There is that. Altho I'd classify testing it (in terms of "does this meet 
the spec" and not in terms of "do the users like what we spec'ed enough to 
pay us") as part of the design. It's ensuring the design is right.

> doing the next merger already.

Heh.

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message

On 20/08/2011 01:31 AM, Darren New wrote:
> On 8/19/2011 15:05, clipka wrote:
>> Well, not precisely - you still have to translate the design of what you
>> want to build into a computer-palatable language. And it so happens that
>> often you find out during this phase that you weren't clear about what
>> *exactly* you wanted to build.
>
> That's part of being sufficiently exact. If you're sufficiently exact,
> the translation step can be automated. (For example, we call that "a
> compiler". ;-)

Lest anyone doubt this, at uni we learned about something called 
Computer Aided Software Engineering ("CASE"). We used a tool called 
Rational Rose. You draw various class diagrams, flowcharts, etc., and 
then press a button, and it spits out C++ source code. If your diagrams 
are detailed enough, the generated code actually compiles and runs, and 
*is* "the finished system".

All without you ever writing a single line of code yourself. Or even 
knowing *how* to program C++.

So yes, if your design is detailed enough, the translation is (or can be 
made) automatic.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message