Quote:
Originally Posted by Hitch
There's a real issue, when you cannot directly show or see the results, and the difference. Same is true, no doubt, in writing C#. The people for whom you are writing it can't see the CODE. Or, rather, don't know what they're looking at. Same here. I coudl SHOW Mary Sue how her Calibre-created MOBI looks, in HTML, but...so what? Her theory is, if she can't SEE the underbelly, why does she CARE?
|
In my field (I normally don't write C#, but embedded software, or backends in PHP), it's like this:
"I have a machine that now does X. Now I'm going to change my setup, and I want it to do Y."
My software:
"OK, I'll just need to change the constants for timer A and B, and then add a small procedure at the end of Task 3. Will take about an hour, maybe 1.5, including testing."
Other software I've seen:
"That can't be done, because I didn't use timer constants, and now have timings splintered throughout the program. Also, I've thrown everything together in one task with procedures named XPTCS() and DRVTLT(), of which I don't know what they do anymore. I'll have to write a new program."
The problem is that my software takes 8 weeks to split up into tasks, procedures, objects, constants, etc... it needs to be designed, documented, and then written.
That other software takes 3-4 weeks to write because it's just pounded out and often tested with trial and error. No design, no documentation.
The customer almost always goes for the cheap software, because he can't see the difference. In the end, the better designed software that costs twice the price brings him *nothing*.
Until he needs to change something.
"Oh, but we don't need to change anything."
In the end, they *ALWAYS* want to change something, somewhere, down the road.
Quote:
|
Doubt that helps. Wish it would. I don't envy you your uphill battle on this front. (Is there anything--anything at all--that you encounter, in that battle, that would provide a kernel of an idea, for a service or website or..? that would address that battle?)
|
I'm a slow coder. To be honest, I'm not good with huge projects that pull stuff from a thousand places with everything changing all the time. Something like a big Wordpress installation hosting 500 plugins all glued together with some custom code here and there sets my teeth on edge. In that regard, I'm not too good a developer.
What I *am* good at is to write small, decision-making software (i.e., embedded software). I design it, document it, and then write and test it, and if given enough time, it *NEVER* crashes. Why? Because one does not simply crash machines in a factory, or a digital billboard or stuff like that. It is also maintainable, and extendable. Why? Because you can't take your factory off-line for a day or two while some dude tries to find all the timers splintered through it (and he will ALWAYS miss at least ONE), or half a month to have some procedures replaced.
That is the one thing I'm trying to get through peoples heads. I'm a software engineer, someone who writes software that has to run and be maintained for 15-20 years, not a code wrangler that slaps something together that will be completely replaced or rewritten every 1-3 years (such as websites).
Therefore, the software I write is more expensive. Yes, you can hire someone who is twice as fast as I am. Easily.
It will cost you less money, but it WILL cost you something else: time when changing something, quality, production speed, uptime, lack of documentation, or whatever. You just can't do the design, testing, verification and documenting I do in half the time it takes me. If one could, *I* would do it.
Everybody wants these:
Good Quality of code/maintainability/docs
Short development time
A Low Price
However, you can't have all three at once. Choose any combination of two, and the remaining one will be opposite. (So short development time and a low price gets you bad quality.)
In short, my selling point, as compared to most people I've seen in the field of embedded software engineering / factory automation is that I write software that can run and be maintained forever as long as the machine exists.
Most people who are writing the software for those machines aren't really at fault, actually. Often, they're the hardware engineers, cajoled into writing the software, by management skimping on software engineers, or they 'tried some programming and it wasn't that hard: it actually worked. So we can do it ourselves.'
I don't even have to write the software myself: I can design self-contained objects, procedures and tasks that can be coded by others, and verified through testing. Then I can put everything together, and it will work. That's because of the simple principle that if you make a correct addition to an already correct system, the result will be correct as well.