01-07-2011 08:36 AM
The OP wrote in the very first post:
I'm looking for a quick and dirty solution.
Project side of view:
I personally feel it more problematic to deal with developers that are still looking for a yet better solution than with those that apply cheap hacks to a product that work in first place (and might lead to headaches in the long term). (*) (**)
I'm inspired be the title of Joel's Duct-tape programmer.
(*) Secondary effect is that 'do-ers' learn faster (by their own mistakes).
(**) I'll also get the same long-term issues when a developer uses a too complex design for his experience level.
Technical side of view:
We are really burnt by the heavy overdose of global-abuse you find in code written in a C-variable style.
In such situations where it's simply an abort flag between two loops, it'd say a simple task so a simple fix is enough.
Experience from my own projects: my own code suffered from trying to avoid a global (abort flag) or replacing an existing abort-flag global with 'proper' programming style (notifiers, user-events). Instead of a simple single race condition to look at, I got a more complex problem with more locations for bugs (Is the notifier initialized? What happens if initialization fails (on error)? Is it properly send on error? Is it properly received on error? Is it properly reset on error? Is it properly destroyed?).
Felix
01-07-2011 11:07 AM
@f. Schubert wrote:
The OP wrote in the very first post:
I'm looking for a quick and dirty solution.
Project side of view:
I personally feel it more problematic to deal with developers that are still looking for a yet better solution than with those that apply cheap hacks to a product that work in first place (and might lead to headaches in the long term). (*) (**)
I'm inspired be the title of Joel's Duct-tape programmer.
(*) Secondary effect is that 'do-ers' learn faster (by their own mistakes).
(**) I'll also get the same long-term issues when a developer uses a too complex design for his experience level.
Technical side of view:
We are really burnt by the heavy overdose of global-abuse you find in code written in a C-variable style.
In such situations where it's simply an abort flag between two loops, it'd say a simple task so a simple fix is enough.
Experience from my own projects: my own code suffered from trying to avoid a global (abort flag) or replacing an existing abort-flag global with 'proper' programming style (notifiers, user-events). Instead of a simple single race condition to look at, I got a more complex problem with more locations for bugs (Is the notifier initialized? What happens if initialization fails (on error)? Is it properly send on error? Is it properly received on error? Is it properly reset on error? Is it properly destroyed?).
Felix
My approach is generally to do things the right way and approach all of my code with the thought that I will reuse it in some other application. Over time you start to build up libraries of reusable code that handle these types of issues. This makes it easier to teach new folks proper techniques, it leads to faster application development because of the increased reuse and when using the techniques regularly they become second nature so they really aren't that complex anymore. I have burned too many times using the quick and dirty approach that results in code that is very difficult to maintain. Ultimately you end up spending more time shoehorning in code to work with the poor design than spending a little time up front to insure you have maintainable code.