Re: Disobeying jet engines - why?

In message <9nlsp35asmtgjb00l601qnrgr6at66tnhg@xxxxxxx>, John Larkin <jjlarkin@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> writes
On Mon, 28 Jan 2008 13:55:38 -0800, "Joel Koltner"
<zapwireDASHgroups@xxxxxxxxx> wrote:

"John Larkin" <jjlarkin@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:2dhpp3p0ahl3qm4co9ms0jgiqak12vp7tq@xxxxxxxxxx

So it dawned on me
that he didn't ever give a damn about my problem, he just wanted to
fiddle with databases. Similarly, there are lots of programmers who
aren't interested in your dinky buttons and LCD's, they really want to
get into context switching and schedulers and dynamic memory
assignment algorithms.

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.

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

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.

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.

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.

Fire them.

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.

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

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.

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.

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

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

http://www.vis.uni-stuttgart.de/vis03_tutorial/

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

http://www.sciencesoftware.com/product.php?productid=241
(not a specific recommendation for this package just as an illustration)

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.

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

--
Posted via a free Usenet account from http://www.teranews.com

.