A place to discuss Joel on Software. Now closed.
This community works best when people use their real names. Please register for a free account.
Joel on Software
Business of Software
Design of Software (CLOSED)
.NET Questions (CLOSED)
Fog Creek Copilot
The Old Forum
Albert D. Kallal
I work in embedded software. One of our problems is that the hardware design types control what features are available for us to use to "get the job done". Can anyone think of a nice simple phrase that we can start to use to get the hardware types to help up make a better product faster and with less problems.
Also are there any recommendations on web sites or blogs that might give us some pointers? Our biggest thing is that we want to write robust software and many times it is difficult due to the cost cutting in the hardware design.
The only way this will work is to change the hardware development process and include software developers (and probably mechanical designers if applicable) in all design reviews. This is the way we do it and it really works. It also helps if some of your software guys have an EE background and can "walk the walk" so to speak.
Just having hardware design it and then throw it over the wall to software has been a known path to failure for at least the last two decades. This was a big impetus for the "concurrent engineering" focus in the late 80's.
I feel your pain. I've been there where the EEs wouldn't add a 50 cent part to an $8,000 machine because it "cost too much" and that resulted in months of additional software work to get around the missing functionality.
You could call it "transparency", as in "The hardware should have sufficient transparency that the software can take advantage of, to make the hardware/software combination work in the most efficient and effective way."
What this means in practice is having the hardware drive I/O port hardware that the software can then access. This should include some interrupt generation hardware to "wake the CPU up" at convenient times -- at LEAST a 'timer-tick', and perhaps a few more interrupt bits for critical events.
Another term is "System level balance", as in "we want to balance the system functionality such that the hardware does what it does best, and the software does what IT does best, to make the system level performance as good as it can be."
And yes, in most projects there needs to be some give-and-take as reality intrudes on a good design.
How about "discoverability"? That's what I think of when I think of an API that's easy to use even without reading any documentation, as opposed to an API that's hard to use even *with* the documentation.
In an API that's discoverable, the names are clear, the design is such that it's easy to create new instances of classes and do things with them, and the results are easy to understand.
In an undiscoverable API, the names are confusing, there's no logic to whether properties or methods are used, and there are weird ways to detect status or figure out what effect something had.
Take the Timer class in .NET. It has an Enabled property, which you can set to true to start the timer or set to false to stop it. But that's not half as clear as the Start() and Stop() methods that the Timer class also has. Those are clear and logical to the average person, and they make the timer easy to use.
Examples like that, both good and bad, might help them understand the ideal you're striving for.
To add to the above, here's a decent (concise) article on discoverability, including a (bad) example:
You can Google and find others.
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz