Mantras for developers

They generally don't have the necessary technical education. So the best solution to something like this

But, they *should* be the closest thing to domain experts in the company! Shirley you wouldn't expect the engineer to know what the customer wants, is buying from competitors, needs, etc.?

I made a new product presentation to an employer in the early 80's -- to replace a 20+ year old analog control system with something more fitting the 20th century. I had an audience of 20+ people from across the company's departments (AFAIK, it was the first time someone had ever

The Sales folks would confidently/assertively make demands about features that I had elided from my "new" design, claiming they were *essential*. I would then tell them how many units of the existing design were sold with that "option set" -- usually *one*. At one point, the owner of the company added "... and it's probably sitting on a shelf, there!"

I didn't make many friends in the Sales/Marketing departments that day. But, the owner looked at me really thoughtfully...

When the director of Marketing cornered me after the meeting to complain about how bad I made him look, I replied: "Phil, I asked you for the sales history of the existing product a few weeks ago. You made a lot of excuses but essentially told me you didn't have any data (then how can you know what your customers are buying???). So, I went through the purchase orders from teh last 20 years and MANUALLY tabulated the number of each variant that was sold. Isn't that what you would EXPECT someone coming up with a new product proposal to do???"

Engineers operating without domain knowledge *imply* some sort of structure on the problem that may not exist, in reality. So, when a customer encounters the product, it "feels wrong".

You know the mindset: the type that expects you to fill out a form from top to bottom as they can't imagine your using it any other way!

While you might *think* having an "excuse" to do more development is A Good Thing (as it keeps folks busy "working"), you've given the customer an opportunity to look elsewhere. Now, he "knows" what he wants and can go looking for it, explicitly.

You want to anticipate his needs/wants and let him realize that YOU have already met them! (especially if you research your competitors' offerings and can subtly insinuate how their products are "lacking")

So you need better managers who understand what engineering is doing. On of the reasons I stayed in my first job as long as I did was that (unknown to me (a fresh graduate) at the time) my first manager was previously an electronics engineer and he was also an excellent people manager. I subsequently found out how rare he was.

It doesn't take a technical education to find out what a customer wants, or think they want.

It does take a technical education to translate these desires into a specification for something that might satisfy them.

Marketing and management quite often have had enough technical education to think that they can do that, and they probably could have done back when they acquired that technical education.

It certainly save a lot of discussion at the time, but leads to a lot haggling about features that turn out to be very expensive to implement.

My technical boss at Cambridge Instruments talked about the bad old days when the physicists threw the specs over the wall to the engineers, which didn't work all that well.

Giving them exactly what they wanted (as opposed to what they thought they wanted) goes a lot faster and appreciably more cheaply than modifying something that was more or less what they wanted into something more or less acceptable in use.

Sure. But that'a generally not what happens.

A manager of electronics designers must understand electronics. If they don't, expect amusing and expensive results.

Of course it does.

I've had several bosses and clients who were EEs. But, it doesn't take long to become outdated with the technology. This is particularly true in systems design and software engineering; people know *a* language and think they are expert on the *science* (No, you're just an old programmer).

I had a boss who took my *detailed* project estimate and cut it in half. Then, kept trying to berate me for "being behind". Of course, I kept my original estimate and could see that I was progressing exactly as expected. (He underbid the job because he liked the technology and, not having to PRODUCE anything, personally, it gave him a place to "play")

He questioned my hardware design thinking some of the components weren't necessary. In particular, a pair of counter/timers that he thought could be implemented in software (by counting carry-outs signalled by interrupt routines -- eight of them!). Of course, I had already considered that when designing the hardware and had determined that 15% of the processor would be spent handling just THOSE IRQs.

When you don't have to do the work, its easy to come up with ideas! :>

I had another employer that put a MechE in charge of a project that was almost entirely electronics and software. And, a *technician* in charge of writing the software "because he had a TRS80 at home".

Of course, he thought he understood software because he "wrote programs to keep track of the dog shows in which he'd entered his dogs" (!)

What's that:

I think there are around 3000 distinct programming languages.

What's hot these days? Rust is old fashioned I guess.

Did I suggest that it was? The woods are full of bad specifications, and the people who write the bad specifications tend to be unhappy with any suggestion that the specification could be improved.

It may take a technical education to realise the implications of what's being asked for, or to write up the requirements in a way that will make sense to the engineer who has to satisfy them, but listening carefully and recording what has actually been said doesn't require a technical education.

What you got a Tulane wasn't a technical education - Tulane probably couldn't have delivered that anyway, but you ignored large chunks of what you were taught because you couldn't see the relevance.

One of the best companies I did work for had a whole document series for any new project. From initial requirements, Alternatives and Feasabilities study, One of which would be chosen. Skipping some, then the initial spec, not only what will be delivered, but more importantly, what will *not*. Try to build in flexibility and scope for change, but at that point, the spec is red lined and frozen That's what we build. Change still possible, but hell and high water to do it.

Problem with a lot of software projects, is that the spec changes significantly, during development, which can involve major changes under the hood, and is very disruptive to building a stable platform. Often because the client, being technically illiterate, had no clue as to what they wanted, and kept adding "nice to have" bits, where a basic working system would have served them much better, perhaps saved them millions.

Suspect that's why so many public sector projects in the uk end up grossly over budget, and years late, if at all.

This "waterfall" approach has fallen out of favor -- because people don't KNOW what they want (but will know what they DON'T want when they see it implemented! Harken "Agile"). Indecision and impatience lead to the mistaken belief that they are now MORE productive due to "continuous integration".

I'm replacing SWMBO's "bookshelf HiFi" with a media tank and a small display/UI that I rescued (ignoring all of the server-side software):

But, the new implementation has to be backwards compatible with the old -- she operates the old from memory when she awakens in a darkened room in the middle of the night; she KNOWS where the buttons she wants to press are located on the remote and can easily point it in the direction of the HiFi.

So, the first order of business is to qualify the operations of the existing device as those will have to be mimicked -- it's not an opportunity to start over from scratch!

This has taken me a bit over a man-month, so far. Which buttons affect which displays, at what rate do they blink, what happens if you abort a sequence of steps in favor of another, etc.

Once done, I will use that "stakeholder's spec" to write an engineering spec. The engineering spec will rationalize any changes that I make to the stakeholder's spec (e.g., the existing device supports 6 CDs's -- the new one will support 10 "play lists" where a "playlist" is a virtual CD; the CONTROLS for the dual cassette deck -- not currently used -- will invoke the "falling asleep music program" and the "waking up music program"; etc.)

Once THAT is in place, I will already have made all of the design decisions and just have to write the code to meet those goals -- a relatively mindless task *if* I have given ample thought to the problem (and not just made a "features list").

The goal of the developer (individual or firm) is to elicit that information from the client/customer. This requires familiarizing yourself with the application domain so you understand the issues that the client/customer must address -- even if HE doesn't know how to give voice to them.

When I interview clients (to determine their needs and priorities), whenever the client responds to a question with "I don't care", I mumble "In case of <whatever>, device should catch fire and electrocute the user".

Of course, this immediately meets with very vocal objections. "Ah! So you *do* care! OK, lets take some time to figure out what you REALLY want so you aren't disappointed that I opted to make my own decisions (in MY best interests) for anything that you left unspecified ..."

The wrong people (non-tech) are making the decisions and being advised by people (tech!) with no knowledge of the application domain. How could you expect this to ever work??

"Do you want to end up with a successful product? And, a smart investment? Or, do you just want to be busy for some period of time and not concerned with ever showing results??"

One of SWMBO's work colleagues needed a database system (DBMS and associated forms) created. I interviewed him for a few hours. Looked at my initial idea of the effort ($$) required. And, the likelihood that his needs would change after the project was authorized.

I politely "No Bid" the job -- much to his dismay (what am I going to tell him; he is clueless as to his needs and approach??)

Customers don't often have a detailed, complete definition of what they want. They may not even know what's possible. They have a problem, and if we can help them understand what might help, we can make a friend and design cool stuff for them and often wind up with a new generally-sellable product.

Someone who desn't understand electronics can't do that.

You know nothing about Tulane or about the courses I took. Some were excellent. I was concurrently designing steamship control systems and pipeline supervisory controls and flight hardware for the S1B and C5A.

It was interesting that I took a grad-level course in communications theory while I was also designing modems for the supervisory control systems.

Things have worked out pretty good so far.

It was about 9000 a few years ago. See my postings in the "dead programming languages" thread on SED circa February-March 2023.

.<https:/hopl.info>

and

.

Gets a lot of press anyway. Was mentioned in 2023. Pretty low in the Tiobe Index in Aug'26.

Joe

a specific application.

You'd be foolhardy to use C to access a database. Or, SQL to control a temperature loop.

Languages encourage/discourage specific usage paradigms. My system is object-based -- yet written in (primarily) C. This makes some things harder -- but lets me avoid some other issues associated with OOPS and the languages that target that sort of application. Do I have to give a name to my bastardization of C syntax to make it recognizable as a "new language"?

If I design an ASL for a particular project, does *it* need a name?

Here's the "language" that I designed for an audio annunciator many years ago: AUDIO (enter an AUDIO language code stanza) TEMPO <beats_per_minute>

PLAY <note> <duration>

REST <duration>

SLUR STACCATO STACCATISSIMO GLISSANDO MARCATO SEGNO DSALFINE QUIT (leave stanza while retaining ownership of device) END (leave stanza and release device) It makes creating melodic annunciators simple and terse. Gotta wonder what the code looks like for the annunciators in my stove, refrigerator, TV, etc.!

Does that make it #9001?

But you can't afford to send out people who can do that to every possible customer. You need less valuable people who can visit potential customers regularly and find out when they are in a position to spend money on that kind of development, and only then call in the kind of more technically educated person who can clarify the customer's half-baked desired.

But you can split up the job between the initial reconnaissance (which should be done at regular intervals) and the exploitation of a potential opportunity (which will come up a lot less often).

I know what you have posted here, and I know Tulane's position in the university ranking's - 69th amongst US universities.

In your opinion. Chemistry wasn't and you skipped classes and faked your lab results. I didn't and my colleagues did comment on the frequency with which my lab results kept reappearing.

Under supervision.

Anybody remotely sensible would have done that. There's no visible evidence that you learnt anything useful from the course. I did a first year course at Melbourne in Computer Science as a graduate student which was useful, because my tutor had written his M.Sc. on non-linear multi-parameter curve fitting and lean me his M.Sc. thesis (which is cited in my Ph.D. thesis). Grad level at Tulane isn't a exactly high level course.

As assessed by you. Egomaniacs tend to satisfied with what they have achieved.

Chemistry courses were awful. They were a freshmen washout course.

And I faked the EE lab reports, not chemistry.

I did the circuit design. That's what I do.

The comm theory was a bunch of math and no help designing FSK modems. One thing that would have helped was a discussion of delay distortion, but that wasn't mentioned.

I got a B, because the only grades they gave for grad level courses were A, B, and F.

Ok, you run your company your way and I'll run mine my way.

John Larkin Highland Tech Glen Canyon Design Center Lunatic Fringe Electronics

In fact, that comment, or similar was in the Xinu / pdp11 process context switcher, which was in unix format asm.

Needed in depth understanding around the finer points of pdp11 operation to understand that, but an interesting challenge, none the less. Several years of Macro 11 by then, but still took some time to understand it.