The software has bugs – and we know it.
Let’s get this one out of the way first.
No software vendor likes to do it but production code is released knowing it contains unresolved bugs. Why isn’t every release bug-free?
- Debugging large problems takes a long time.
- Some bugs are in 3rd party libraries so we’re at the mercy of someone else’s schedule.
- Other bugs are so minor that they never get too high on the priority list. (I have a knack for finding and reporting those kinds of bugs – things like a typo on the 3rd page of Help, About.)
- There comes a time when you have to release the fixes you’ve already made while you continue to work on the remaining ones.
What’s the old adage about software? Every program has at least one bug. And every program has one line that can be removed without affecting functionality. Therefore, every program can be reduced to one line with a bug. It’s kinda like that.
There are some feature requests we won’t ever implement.
Every software provider wants to satisfy its customers. So when the customer says “it would be nice if…” another task gets added to a to-do list. And another and another and another. But no vendor is going to implement every customer request. Why not?
- Feature requests often conflict – person A wants a button to be red but person B wants the same button to be blue.
- Feature requests often don’t reflect the true underlying issue. In the button example above, maybe the color helps find the button because the panel is poorly organized or too long.
- Some requests are of the form “cure cancer.” I suppose with enough time we’ll get there. But that doesn’t make the requester prescient.
- And a minority of the requests just aren’t right. Use dongles for license management? Ain’t gonna happen.
This may sound a little flippant but a lot of requests simply aren’t actionable.
There’s no such thing as a small feature.
Well-meaning customers often ask for changes to the code and follow-up with a comment to the effect that “this shouldn’t take long for you to implement.” Unfortunately, that’s never true. Here’s why.
- Changes to the user interface have to be reviewed to ensure consistency with the rest of the application. Documentation and on-line help, including all those screen shots of buttons, have to be updated.
- Changes to core methods have to be tested to ensure they don’t conflict with existing capabilities. (Trust me on this. A change to one parameter in one method to improve one customer’s experience can drastically worsen the experience for another customer.)
- Then there’s the writing of test scripts for the new method and integrating those into the automated nightly processes and whatever manual testing takes place during a release.
So while most any feature is do-able, it usually takes longer than anyone thinks (or wants). Plus there’s the issue of opportunity cost – what won’t get done while we’re adding this new feature.
We can’t tell you when we’ll release – can’t, not won’t.
Customers want to know when new features will be released for good reasons. Maybe there’s a project on which they want to use a new feature. Maybe it’s a major release and they’d like to schedule training. However, release dates are awfully hard to predict.
- The scope of a project changes in the midst of the development cycle. Features get dropped, features get added. We learn that a feature is going to take five times as much effort as originally thought.
- Personnel issues (things like family vacation, jury duty, and other assignments) play havoc with schedules, especially in a small company. For example, there are days like today when four people call in sick.
- The rush to achieve a particular date is usually bad for morale. And the date, after all, is relatively arbitrary. Finally, as Fred Brooks wrote in The Mythical Man Month, adding staff to a late project just makes it later.
I’m a recovering addict – addicted to release dates. I’ve learned that feature driven releases, not date driven, are better for everyone. Don’t get me wrong – we compute an estimated freeze date on a monthly basis. But there’s no sense in reporting it as it tends to change a lot.
Are there other secrets?
Certainly. But you don’t expect me to reveal them all, do you? Maybe someone else can share their secrets in the comments.
RSS - Posts
As a CFD developer I would like to add some of my own. But they are not secrets. (BTW, I am a one man show and I don’t have a PhD with this stuff (or any other stuff) so I can’t say I represent the industry.)
1) In general, simple geometries kick the tires of CFD codes more than a complex geometries
I deal with implicit time marching compressible codes. As long as my cells don’t have negative density or energy I’m most likely going to get an answer. It may be “wrong”, but it will still be a “right” looking plot. One way to get an answer is to turn down the CFL number. However, the CFL value doesn’t have much depth to many people and even when it means something, one is not sure what it is telling you. If the code requires a small CFL it could be because of bugs or complex physics. Complex geometries are great!! CFL number will likely be low. There is also good justification for the solution to be unsteady. And a lot of times I can’t point out the errors even when I know they are there because they are washed out by everything else going on. And, if I can’t do it, my ego would like to think that many people can’t do it. Also, if there are many cells with different sizes and shapes no one will be likely to point out a cell subtlety behaving badly and the mixture of cells tends to wash out the error.
On the other hand, take a simple axisymmetric ogive cone with a structured grid. Boring, but geez, those are a pain.
2) Was that a bug or physics which got transported by?
When a cell has a bug in it, it creates noise. Think of it literally as a bug buzzing away in a cell. This information gets turned into physics (i.e. flow values) and transported away. And it is a stream of noise, sort of like dye injected into a flow. Unfortunately you might not be able to see it, or differentiate it. If there is another area which is sensitive to the noise, such as an area about ready to to unsteady, it could be tripped. It is easy to attribute the affects of a bug to standard physics. So sometimes it is a matter of wait and see. One hopes a test case will come up which either points to a bug or real physics. (Think of it in day to day terms, you may be in bed at night annoyed by a bug flying around, but, can you find it and squash it? Maybe it is best to just put your head under the pillow and try to get some sleep.)
3) Discretization standards don’t exist all the time.
Take something as basic as the viscous tensor on a structured or unstructured cell. I don’t think there is a standard (or even best practices) on how that is discretized. Unfortunately, when combined with the high eddy viscosity values of a turbulence model, small differences can create large load differences.
4) There is more to the cell than just modeling the physics.
There is also the solution methodology. Explicit, implicit, ADI, etc. And it is sooo easy to sweep the details of that under the rug. Rest assured, some of that is borderline black magic. At least IMO.
Thanks for sharing, Martin.
I really like your first point about the benefits of simple geometries relative to the complex. It reminds of golf – “Drive for show, putt for dough.” Those complex geometries are like monster tee shots on a long par 5 – they look great and can be really impressive. But often the difference between victory and defeat comes down to the ability to make a 20 foot putt.