Disobeying jet engines - why?

And I thought I was irrational not wanting to fly without any greater threat to my life...

:-)

Dimiter

------------------------------------------------------ Dimiter Popoff Transgalactic Instruments

------------------------------------------------------

e

we did exactly that. I kept a copy of his RTOS, as it was kinda sexy, but gross overkill. his previous job was coding for expensive laser copiers, where he had Mb of RAM.....

the moral of the story is: never hire computer scientists.

Cheers Terry

As Phil Hobbs has noted, and field of study that includes the word "science" in its title isn't one.

John

Indeed. And any computing project with the word "integrated" in its title is doomed to be a costly failure.

Cheers Terry

I worked on the "Integrated Crypto Feature" (mainframe crypto coprocessor). While it didn't make any money itself, dragged along a few hundred million worth of computers, software, and services.

--
Keith

If its Windows, passwords don't do any good.

--
Paul Hovnanian     mailto:Paul@Hovnanian.com
------------------------------------------------------------------
Sacred cows make the best hamburger. -- Mark Twain

So true, 0PHCRACK is one way, booting it with Knoppix is another. The only other measure is to completely encrypt the drive.

I think even more would-be programmers have simply been sold a bill of goods by those who'd like to sell you databases, RTOSes, etc. in the first place -- they have a difficult time conceiving how the problem ought to be solved "from scratch" so they fall for the advertisements telling them that all their problems will become trivially simple if only they send over a purchase order.

Don't hire them in the first place; the guy in your example sounds like he'd be an excellent employee at a company -- just not *your* company.

The problem with programmers, even worse than with engineers, is that you don't know how good they are until after you've worked with them for a while. Programming is especially bad, as it's hard to judge quality when something is 90% done, and everything is always 90% done. Hardware design is a lot more visible.

I had a friend who started up a nanotech business and hired some software jocks to do the analysis and visualization stuff, pretty heavy code. All they seemed to do was rave about Java. It gave me a bad feeling. Sure anough, all they wanted to do was play with Java. It cost him a year and a half, and a few hundred kilobucks, for zero results. We demoed and sold his first system running my 5-day PowerBasic hack.

John

I think this is a good illustration of the reality. A true programmers week is more productive than a bunch of typical programmers two years. If _you_ find it difficult to see if someone is a good programmer, think of all those clueless "managers", it is just hopeless.

Dimiter

------------------------------------------------------ Dimiter Popoff Transgalactic Instruments

------------------------------------------------------

ge

ods

e -- =A0

"from

rder.

e'd

[snip the rest]

this, IMNSHO, is why computing seems to be such a refuge for the incompetent. The vast bulk of business people dont know much at all about computers, so someone with even a little knowledge can appear to be knowledgeable.

The funniest thing I have ever seen an IT guy do is run disk doctor to try and prevent a title page being printed out on a network printer.

he used to be the production QA guy - a position he was promoted to as his failure rate was so high. thanks to a synergistic combination of cluelessness and clumsiness.

Cheers Terry

In message , John Larkin writes

I wish I could say it wasn't true. Although if you are doing genuine RT work you do need an engineer who understands what semaphores are for and how to design a things to prevent deadlocks occurring.

There is always the risk in computing that using the bleeding edge new stuff is sexy and in a poorly managed environment (and sad to say many software shops are badly managed) they tend to adjust things to justify getting in the newest latest and greatest toys. Inevitably the salesman, on commission sells them the most expensive stuff he can get away with...

If you have a specification of what you need from the software then it is harder to get sold a gold plated elephant when you wanted a pet mouse.

Sometimes the right thing to do is to buy the correct development tool for the job. Anyone who attempts to write a database from scratch for a PC wants their head examining (and that was true almost from the early days of CPM). Same with anyone who attempts to debug embedded code in a hard RT environment without using the right tools.

There always needs to be one gofer to fetch the coffee and fill in paperwork.

Indeed. I can't argue with that. I span the border between electronics and software though I mainly develop software I can at a pinch design electronics and find complex faults in other peoples circuits.

Intermediate deliverables where some percentage of the required functionality is 100% done and usable is one way out of the madhouse. You need to prioritise the important parts (high risk or essential to success).

Function creep is the enemy of successful software projects.

Newest latest and greatest problem. For a one time data visualisation problem there are several scientific data analysis packages that would do. eg.

Depending what your friend actually wanted to do there may well have been off the shelf components that would do most of what he wanted. Good data visualisation packages cost between $1-5k per seat. eg

(not a specific recommendation for this package just as an illustration)

What deliverables did he negotiate with the programming team?

The safest way to develop software when you don't know exactly what you want and the hardware is still evolving is to rough prototype the absolute essential core in a very high level language and then take a look at it.

If you don't have a good plan when you start out on the final version you will never know when you reach your goal. Bells and whistles can come later - by all means plan for them but develop it in the strict order needed to deliver something that is useful and testable against the hardware.

Badly thought out architectures and design goals tend to become gaols.

In civil engineering you generally would notice if someone starts building a wall out of true, with mismatched crumbling bricks and on shifting sands with no foundations.

Sadly in software there is no such easy laymans visual test for good software. Most people can be fooled by a cute GUI on a pile of the proverbial provided it doesn't fall over too often.

Metrics like McCabes CCI or cyclometric complexity index is a fair indicator of how much of a maintenance trap you have on your hands. But it only works on the code after it is written. It measures how many distinct paths there are through the code and how many test cases needed to execute them all. A rats nest detector if you like.

Regards,

--
Martin Brown

...

Well, I was in the process of digging my way out of a poverty hole I'd managed to get myself into, and temping is the quickest way I know to get a job TODAY, and eat by Friday. :-)

Cheers! Rich

I am. ;-)

Unless, of course, you consider a "main loop" to be an OS. ;-)

Cheers! Rich

Yeah, I guess, but isn't it more like a monitor [1] plus a disk handler? ;-)

Cheers! Rich

[1] A monitor program is one that, like DEBUG, lets you look at memory values, enter values, do certain limited things, and like that. Maybe the difference is that an OS can load and start different processes on the fly?

On a sunny day (Tue, 29 Jan 2008 19:52:59 GMT) it happened Rich Grise wrote in :

The sort of (others may have their own ;-) ) definition of 'Operating System' is a system that creates an universal interface (API) to applications, independent of the hardware.

As CP/M consist of 3 parts, BIOS (the hardware layer), BDOS (basic disk operating system), and CCP (command processor), it was a totally new, and badly needed concept at that time. The universal interface to 'files' like open, read, write, close, seek is a particular very strong thing added. Having the command processor interface allows a user to do things, like copy files, start programs.

CP/M, in its original form, was single tasking, just like that MSDOS that came later, and was a cheap hack, copycat.

The 'OS' concept made it possible to write software that ran on different hardware. That took computing a huge step forward.

[snip]

operating

I was working someplace where they bought a copy of CP/M to run on some S-100 computer. You had to write your own BIOS. ;-) You got a "skeletal bios", with entry points and stubs, to provide the interface, but you had to write your own hardware interfaces. :-)

BTW, CP/M is for "Control Program for Microprocessors." :-) ;-)

Cheers! Rich

That's not abuse - that's caution.

Cheers! Rich

When I bought my first Windows 95 computer, I also bought a copy of VB 4.0, primarily because I had heard other geeks rave about how in-demand VB programmers were.

I found it rather cool, and actually made $20.00 writing a program for my brother. :-)

Cheers! Rich