embracing retro 'puters

[JimMarn]

If memory serves IBM tried to regain control of the PC platform with the proprietary MCA (to kill the clones), but by then everyone had got used to buying clones for half price, so it was too late.

PCI was much later.

I remember that. One store I went to had clones for a around $2,000 to $3,000. The IBM pc was $7,000. The store didn't last long even though it was in a shopping mall and lots of people wanted a home computer. The store was crowded on weekends.

It didn't help that the store owner only hired people with sales experience. I tried to work there, I was working on my Bachelors of Science in Computer Science, and he said I needed to go to school to learn how to be salesman.

One of my relatives went there with her then boy friend, and the sales clerk basically destroyed the demo computer.

 

[Ulsyus]

Out of curiosity as I didn't remember exactly what von Bismark said about laws and sausages, I found this treatise that he may not have said it at all.

There are adverts on thge page and I have a popup blocker running.

https://quoteinvestigator.com/2010/07/08/laws-sausages/

quoting from the page linked to:

The Daily Cleveland Herald, March 29, 1869, quoted lawyer-poet John Godfrey Saxe that “Laws, like sausages, cease to inspire respect in proportion as we know how they are made,” and this may be the true origin of the saying.

end quote.

I thought von Bismark's quote ran something like

Laws are like sausages, it is better not to see them being made.

...which is a reference to the at-times less than mature manner in which elected representatives may interact while in the process of proposing, debating and approving new or amended legislation.

 

[Straybow]

That is why megacorp software cost millions and generally work.

No, it costs a particular amount because somebody sat down forty years ago and made up a cost structure for all the programs used in the ship's computer. There was no great effort at rationalization of what the programs actually did and why it would cost so much.


When the rule says it could be written in a week, it reveals some of the actual rationalization of the scope of work. It isn't that much, really. The rule didn't differentiate between generating a J1 plot versus a J6 plot, one software package does it all equally well.



Second, nobody said it is megacorp software. Shipyards in some cases are government owned or local enterprises. Everything has been standardized for a couple thousand years. Any assumption of megacorp ownership of the code is just that.

When we hack things for our own use we can be vastly more productive. No-one said anything about regulated 40 h weeks.

When one says "one week" and requires the exclusion of all other tasks except eating and sleeping, then you'd have a point. As is, it just says "one week" without qualification. You don't have to be free of other duties or projects. That means the time requirement is standard 8 hours × 5 days and can be compressed with overtime. This 8 hour shift standard is mentioned many times in starship staffing requirements, which is the basis for all the tasks in Traveller.

Of course, you may GM as you please.

Generate can be written by a highly skilled professional (Comp-3) with the help of an extremely skilled astrogator (Nav-4) in average between a month or two working for themselves. Without extremely skilled input you can't write the software at all. The requirements means that neither the code nor the underlying problem are simple, nor is it a trivial amount of code.

Except that isn't what the requirements say. Comp-3 does not remove the "hidden bug" danger. Nav-4 does not remove the "hidden bug" danger. Spending a month or two only comes closer to guaranteeing success, and does not remove the "hidden bug" danger.


The fact is, if the programming team is successful in the first week, it's just as good as the team that keeps trying week after week until successful. It is, therefore, a fairly small amount of code, and the actual difficulty (including debugging) isn't a monumental task you're making it out to be.


Again, the fact that generating J6 plots doesn't take any more programming skill than J1 plots says the generation is fairly simple, it is the technology of the hardware that matters. If there were separate generate packages that could handle each higher level of jump there would be justification for saying the task of generating a plot is increasingly difficult.

 

[Straybow]

When we hack things for our own use we can be vastly more productive. No-one said anything about regulated 40 h weeks.

One other point. Enterprise software is buggy precisely because it is a case of design by committee combined with oversight by committee. The programmer is typically handcuffed by a list of features, each being something somebody high up wants because marketing says people are looking for those features, or because he or she read an article about that type of feature in some other product.


The individual programmer rarely has control of a whole project, but simply has an assignment to take this input and do that with it, or some such. Then it is up to other people to integrate this code with that code, and so on.


Then the programmer gets his code back and they say that this and that are problems. The poor schlub may have to debug without actually seeing the code that calls his code or that uses his output, because none of the code is in any stable form yet.


This is a case of thoroughly known architecture using specific input and producing measurable output. It is math in one of its purest forms.


The Nav program, on the other hand, has to work with any jump drive to which it is connected, on any size vessel, and work to execute the jump plot safely.

 

[aramis]

The Nav program, on the other hand, has to work with any jump drive to which it is connected, on any size vessel, and work to execute the jump plot safely.

Does it? or does it come in a variety of standard design versions?
Same for the computer - is it really a universal device, or is it a standard of final performance shared by thousands of bespoke systems, each adapted to their specific "standard" hulls?
And the generate program? is it truly universal? or is it bespoke? Or, like plug-n-pray peripherals in the 90's, mixed - a universal core, with plug ins for data and ship configuration?

CT doesn't answer any of those questions.

 

[Straybow]

Does it? or does it come in a variety of standard design versions?
Same for the computer - is it really a universal device, or is it a standard of final performance shared by thousands of bespoke systems, each adapted to their specific "standard" hulls?
And the generate program? is it truly universal? or is it bespoke? Or, like plug-n-pray peripherals in the 90's, mixed - a universal core, with plug ins for data and ship configuration?

CT doesn't answer any of those questions.

Hmmm, it seems I've temporarily lost track of my LBBs and my cheat sheets don't cover construction. So I'll answer to the best of my recall.



No, everything is universal. If you buy a standard design and then later update the drives there is no need to buy new software. Likewise, if you updated the computer to handle more programs you don't have to buy new software. What you have always works with anything. Unless there is a jump program specific to jump number, which would be specified and therefore an exception. As I recall, there is a jump program that can do all jumps that the ship can do, if you wanted to spend the money and had a computer big enough to handle it.



For Generate, definitely not. If you took battle damage and had to replace the computer, or decided to upgrade, you don't have to replace programs. You may be sectors away from the originating shipyard, where even the megacorps aren't the same. The new computer works with the old software.


Likewise, you could get a new ship and take your old programs with you, and they would all work. Or take your old computer with you, and all the new programs for the computer the new ship came with would work on the old one. And so on.

 

[kilemall]

Hmmm, it seems I've temporarily lost track of my LBBs and my cheat sheets don't cover construction. So I'll answer to the best of my recall.



No, everything is universal. If you buy a standard design and then later update the drives there is no need to buy new software. Likewise, if you updated the computer to handle more programs you don't have to buy new software. What you have always works with anything. Unless there is a jump program specific to jump number, which would be specified and therefore an exception. As I recall, there is a jump program that can do all jumps that the ship can do, if you wanted to spend the money and had a computer big enough to handle it.



For Generate, definitely not. If you took battle damage and had to replace the computer, or decided to upgrade, you don't have to replace programs. You may be sectors away from the originating shipyard, where even the megacorps aren't the same. The new computer works with the old software.


Likewise, you could get a new ship and take your old programs with you, and they would all work. Or take your old computer with you, and all the new programs for the computer the new ship came with would work on the old one. And so on.

I assume that the megacredit purchase price includes lifetime support, updates, shipyard support for replacement/upgrade components, etc.


My cheaper grades of computers and programs require more backend support cost- or turn the crew programmer loose with risky consequences.

 

[Blue Ghost]

I assume that the megacredit purchase price includes lifetime support, updates, shipyard support for replacement/upgrade components, etc.


My cheaper grades of computers and programs require more backend support cost- or turn the crew programmer loose with risky consequences.

Well, the game was penned before the advent of online software updates. So there's some retrofitting needed to make them work today.

p.s. your PM box is full.

 

[Ulsyus]

No, everything is universal. If you buy a standard design and then later update the drives there is no need to buy new software. Likewise, if you updated the computer to handle more programs you don't have to buy new software. What you have always works with anything. Unless there is a jump program specific to jump number, which would be specified and therefore an exception. As I recall, there is a jump program that can do all jumps that the ship can do, if you wanted to spend the money and had a computer big enough to handle it.

After a millennia of rule it would make sense that the 3I would have standards (managed by the Imperial Board of Standardisation) that would require the compatibility of software across operating systems.

Given the competition that exists between megacorps, would there be anti-monopoly laws in the Imperium, or would it have elements of the 2I structure built into it, where some corporations were permitted a monopoly in certain areas of the economy/industry but prohibited from infringing on another megacorp's domain? How much competition would exist between computer providers, and what requirement would exist for them to use standardised OS in order to enable greater ubiquity of programs such as Generate?

 

[AnotherDilbert]

No, it costs a particular amount because somebody sat down forty years ago and made up a cost structure for all the programs used in the ship's computer. There was no great effort at rationalization of what the programs actually did and why it would cost so much.

Yes, it's random made up crap, but playing pretend with that random made up crap is what we do here?

When one says "one week" and requires the exclusion of all other tasks except eating and sleeping, then you'd have a point. As is, it just says "one week" without qualification.

Any project planning I have ever seen makes a clear difference between calendar time and man-hours or man-months. One week with several people involved sound like calendar time to me.

Ten lines of code per hour for 40 hours a week is an old approximation used by major corps for large projects, and includes meetings, paperwork, testing, and more testing.

Minor start-ups scoffs at both these numbers and often produce much higher.

Except that isn't what the requirements say. Comp-3 does not remove the "hidden bug" danger.

The requirements clearly state that it takes a very skilled programmer with the help of an extremely skilled astrogator to have any chance of writing the software at all. Without Comp-3 and Nav-4 you have no chance of success (unless the Referee is kind). On average it takes a month or two.

Of course the chance of crippling bugs is always there in home-written software.

The fact is, if the programming team is successful in the first week, it's just as good as the team that keeps trying week after week until successful. It is, therefore, a fairly small amount of code, and the actual difficulty (including debugging) isn't a monumental task you're making it out to be.

Programmers can have vastly different productivity. Someone who has recently written similar software and hence knows the problem, how to design and structure the code, can reuse a lot of code, and knows the specific library code by heart would be much quicker to write the software than someone who sees this for the first time.

That some people can sometimes whip up some software in a week, that it would generally take a month or two to write, is hardly a surprise.

That it takes several people with very high skills to have any chance of success says it is not trivial.

Again, the fact that generating J6 plots doesn't take any more programming skill than J1 plots says the generation is fairly simple, ...

No, why would it?

Generate is same software for any jump, Jump Control is much more complex for higher jumps.

 

[Straybow]

Yes, it's random made up crap, but playing pretend with that random made up crap is what we do here?

Which is why we should ignore made up crap that ceases to make sense...

Any project planning I have ever seen makes a clear difference between calendar time and man-hours or man-months. One week with several people involved sound like calendar time to me.

The made up crap wasn't made up using project management software that didn't exist when the crap was made up. Traveller does not distinguish between calendar time and man-hours, and clearly uses an 8 hour day whenever there is a reference to ship crew requirements and expectations.

Ten lines of code per hour for 40 hours a week is an old approximation used by major corps for large projects, and includes meetings, paperwork, testing, and more testing.

Minor start-ups scoffs at both these numbers and often produce much higher.

Yes, and that's why I indicated that the actual lines of code produced would be far greater with the programmer's own inventory of well tested code blocks and professional code libraries. The 10/hour does include testing, as testing is apparently where the problem lies. If the program isn't finished after the first week, I don't see the programmer just mindlessly adding lines to the project. No, the code merely needs refinement and testing.

Of course the chance of crippling bugs is always there in home-written software.

So, have the party start their own software company. Hire a part time team of experienced executives and write a quick prospectus. Set up a meeting with a venture capital firm (expecting no results). Then hire the party's internal Comp-3 expert (which is probably about the equivalent of a doctorate) to write a professional Generate program for your professional software company as a proof-of-concept work. Voila, it's no longer a "home-written" software, so the hidden bug program goes away. It would probably only cost a few kCr10s and a few extra months. Still a bargain compared to kCr800
:coffeesip:

 

[AnotherDilbert]

The made up crap wasn't made up using project management software that didn't exist when the crap was made up.

The software may not have been available, the methods were old and well established. https://en.wikipedia.org/wiki/The_Mythical_Man-Month

Traveller does not distinguish between calendar time and man-hours, and clearly uses an 8 hour day whenever there is a reference to ship crew requirements and expectations.

Starship crews clearly does not work 5 × 8 h weeks. There is very little to do for much of the crew in jump space, for example.

Yes, and that's why I indicated that the actual lines of code produced would be far greater with the programmer's own inventory of well tested code blocks and professional code libraries. The 10/hour does include testing, as testing is apparently where the problem lies. If the program isn't finished after the first week, I don't see the programmer just mindlessly adding lines to the project. No, the code merely needs refinement and testing.

Or the design (that someone did on the back of an envelope) was non-viable, and you had to start over.

The coding phase may be somewhat predictable, but the "Learning to understand the problem" and design phases certainly are not.

So, have the party start their own software company. Hire a part time team of experienced executives and write a quick prospectus.

The Critical Flaw rule applies to all software you write, regardless of how many glossy PowerPoint-presentations you produce.

 

[aramis]

Given the fine balance that makes merchants just barely profitable, less so than real life wet-merchants, in many cases, and knowing how Marc responds to "here's the math..."

... and how much of the gear section is actually about 1970-1976 list prices...

... I think you're WAY off base, Straybow.

 

[JimMarn]

Some time back, probably in the 1990s, there was a discussion about the Mythcal Man-Month in a newsgroup alt.folklore.computers. Many of the people there worked on/with computers in the punch card and drum memory days.

The discussion as far as I remember it, said that some managers never learned things like: 1 programmer can write software in 360 days, that 360 programmers cannot write it in 1 day.

 

[AnotherDilbert]

If I remember correctly I read it in the late 90s, and it felt very current. Many of the things in the book that was well-known in the 70s that you should not do, was still commonly done in the 90s in my experience.

 

[RandyB]

If I remember correctly I read it in the late 90s, and it felt very current. Many of the things in the book that was well-known in the 70s that you should not do, was still commonly done in the 90s in my experience.

That was the arrogance of believing that the latest methodology, or management fad, or OPEN SOURCE YEEEEEAAAHHHHHH!!!! would overcome the limitations documented in that book.

That arrogance is alive and well today.

 

[AnotherDilbert]

That arrogance is alive and well today.

Well, it can't possibly be a management problem, now can it? So obviously any problems are caused by the current (lack of) process and can be fixed by a new process.

 

[RandyB]

Well, it can't possibly be a management problem, now can it? So obviously any problems are caused by the current (lack of) process and can be fixed by a new process.

And proven processes clearly aren't good enough. Yup.

 

[JimMarn]

Over the years problems have happened in fixing various desktop computers. Not all, but some, jobs a manager suggested to us that several people work on the one computer that refused to work.

We politely pointed out that only one pair of hands could get in there at a time.

"Well, if more of you got in there, it would be fixed faster !"

My boss, or one of us, would point out it was now a spare as the person's computer that had broken down was replaced and all their files copied over, and they were back working.

That didn't seem to make a difference to some of the complainers.

 

[kilemall]

Some time back, probably in the 1990s, there was a discussion about the Mythcal Man-Month in a newsgroup alt.folklore.computers. Many of the people there worked on/with computers in the punch card and drum memory days.

The discussion as far as I remember it, said that some managers never learned things like: 1 programmer can write software in 360 days, that 360 programmers cannot write it in 1 day.

I created a formula called Mittermeyer's Law that expresses this.


It purported to give you a man-hour figure predicated on quality of programmers, too many programmers, friction between all parties, and feature bloat.