Being a software engineer, I can relate to this!
The typical design process is:
Hardware people make a design and any missing/iffy parts are left to the
software people to deal with.
The software people write the code and any missing/iffy parts are left
to the document/manual writers to work out.
Tech writers type up the manuals and any missing/iffy parts are left for
the end user to figure out.
Sounds about right (speaking as a hardware designer). The real
problem is that no one had a complete specification in the first
place. When I worked for IBM, a *complete* specification was a
requirement. The specification was half the work and drove all of the
rest of the above "people".
From another job... Inverting a signal isn't so much of an "iffy
bit". I was once told by our software engineer that flipping a bit
was too difficult because he'd have to release all his code.
Management bought it, so I had to spin a board (several thousand
dollars - and a couple of month hit to the schedule), re-test,
re-release all of the documentation. All *real* money. He had to
re-release his code (something that happened fairly regularly anyway)
because the all of hardware part numbers changed.
On Saturday, May 14, 2016 at 11:08:58 AM UTC-4, krw wrote:
I hang out in an Excel forum and often write VBA macros for people that
submit their "requirements". They'll post what they want the code to do
and I'll respond with a macro that fulfills their stated requirements.
Their next response will often be: "Hey thanks! That works great. Now
can you make it do "this"?" I'll chastise them a bit about incomplete
requirements, rework the code and then post it.
"Hey thanks again! Sorry about leaving out those extra requirements. BTW,
can you also make it do "this"?"
It's at that point that I'll usually ask them what they think would happen
if they were actually paying for the code and kept adding requirements after
the contracted-for specifications had been met. Do they think that they can
just expect re-work after re-work with no implications - either additional
costs or bloated code with all sorts of bolt-ons that impact the efficiency
I can only hope that it plants a seed for the next time they need help -
even if it's free help.
Good luck with that!
BTW, my wife came to me the other day asking me how to get rid of the
annoying message that kept appearing on her screen. It said "Out of
file space". It's beside the point that there is a second drive on the
machine that has 50GB of free space. It might as well not even be there.
I think I'll go find her a few more GB to work with...
I've been watching for decades for things to be different... hasn't happened
and I doubt it ever will. I see a lot of what I refer to as "western movie
set" applications done with tools like MS Access... fancy interface with
barely anything behind it or things that don't work correctly. IT hasn't
supported the Excel or Access apps in any company where I've worked... nor
on the college campuses. Those apps are the business's problem and very few
"in the business" have formal training. IT also hides behind the phrase "out
of scope" as a dynamic business environment moves forward IT checks off
their "in scope" boxes... the finished product doesn't meet the business
needs. It's been like this for decades... Agile is the latest thing to raise
it's head in my business circles... at least it looks like something is
getting done. ;~)
On Saturday, May 14, 2016 at 4:47:57 PM UTC-4, John Grossbohlin wrote:
What's even scarier is that I know for a fact that some businesses are being
run on programs that came from a free-help forum. I know that because I've written
Excel macros to create invoices, track inventory, tracks projects, etc.
The source of most of that problem is a combination of lack of a
clear mission statement for the project, combined with terminal
feature creep. When the programmer starts programming he has no idea
of what the actual requirements are for the program, and before he
gets that (whatever it is) figured out, there are a dozen or more
features thrown in - whether requirements, or just "gee whiz, I didn't
know I could do THAT!!!"
If the requirements were properly laid out, and the processes properly
flow charted, a programmer today could still do the equivalent of
running a full featured spread sheet on a 4K machine with a 4.3Mhz 8
bit processor. And the documentation would be adequate and accurate
enough to allow a programmer 20 years from now to modify it as
necessary - and even understand what the program was doing and how.
In todays (custom software in particular) world, fixing one problem or
adding one feature invariably causes numerous other problems - due in
Large part to totally inadequate program documentation..
On 5/14/16 2:56 PM, firstname.lastname@example.org wrote:
My current project is first defined by the end users (scientists)
dreaming up a set of features that 'would be great' and others that are
needed. Nothing wrong with that, but still rather vague. The hardware
people make the 'mechanics' possible. All the while management wants a
complete middleware design before any work begins. I get a good laugh
when rereading those docs and comparing with what we had to do to get
Some projects are simple enough to do the fully engineered program,
others are just too cutting edge or completely beyond anything done
before you always end up doing the 'spiral' where you get the thing
working, re-design, re-work, etc.
I had an embedded processor that I had managed to get all the code into
a few MBs of memory. At one point someone wanted a web server built in
so they added not one, but two tomcat servers, full blown features,
written in Java. Needed to up the memory from 64M to 1 GB.
The old addage needs to be remembered - first you make it work - THEN
you make it pretty!!. Doesn't matter how glitsy the interface is if it
doesn't do the job.
Or the other one - It doesn't matter if you've got your shit together
- if it's shit - it's still shit..
I seem to run into more glitzy front ends than I do things that work...
Management buys into the pretty front end and assumes it actually does what
the front end suggests it does. I've had to fix three of those types of
apps in recent months. The same developer built all three... and changed
roles leaving the dysfunctional mess behind.
[Build a Bridge] -> <Is Bridge still Standing?> --Yes--> [Good Job!]
^ V------------------ No ^-----------------------
| [Oops!] --> [Add another layer of abstraction and try again]
-------------[Perhaps Regular Expressions would help?] <---
HomeOwnersHub.com is a website for homeowners and building and maintenance pros. It is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.