A few years ago I started to pay proper attention to the possible return on investiment (ROI) of software projects. At the very least, I took an interest in having a very rough estimate of what it would be so I could prioritize better, and whats-more, arm myself with adequate justification.
However lately, I've realized that there's information in that-there calculation that could direct us to make better software, that actually makes more money in the long run by having lower ongoing costs. The big bolt came when I took a niggly support question from one of our support engineers, and was prompted to ask "How often do users ask about this sort of thing?". The answer in this particular case was "lots".
So, this led to me considering a few things about how we can make software that reduces the support load, and secondly, how to financially evaluate a design that does so.
Saturday, 26 March 2011
Wednesday, 9 March 2011
Things I Hate Doing in C++
Why do I do it to myself? Manage memory, manage low-level services, write out loops time and time again, hand-roll all of my thread locking, monitor pattern stuff and observers?
Because I've forgotten to behave like the "real engineer" I claim to be, that's why. If I was behaving the way I was taught (as a mechanical engineer), I wouldn't revisit the same problem over and over, I'd capture a solution once and for all and apply the pattern repeatedly, re-factoring it slightly to accommodate edge cases as I discover them. Now I know that we do this sort of thing in C++ already to some extent: that's what the STL's for. And that's what boost picks up and runs on with for miles more. But it's still not enough. I was also reminded recently that one of my esteemed colleagues had written a multi-methods pre-compiler for C++ (http://www.op59.net/cmm/readme.html), solving an age old problem, and I though, heck, why don't we just do that for all common language problems?
Because I've forgotten to behave like the "real engineer" I claim to be, that's why. If I was behaving the way I was taught (as a mechanical engineer), I wouldn't revisit the same problem over and over, I'd capture a solution once and for all and apply the pattern repeatedly, re-factoring it slightly to accommodate edge cases as I discover them. Now I know that we do this sort of thing in C++ already to some extent: that's what the STL's for. And that's what boost picks up and runs on with for miles more. But it's still not enough. I was also reminded recently that one of my esteemed colleagues had written a multi-methods pre-compiler for C++ (http://www.op59.net/cmm/readme.html), solving an age old problem, and I though, heck, why don't we just do that for all common language problems?
Subscribe to:
Posts (Atom)