In my experience speed vs. reliability soon transmogrifies in inertia vs. rational (and usually inertia wins).
I'd like people that create "quick prototypes" and "just a throwaway excel with a few macros" realized that while they are valuably shortening the time to get something usable they are also shortening the time before their thing turns in a sort of albatross tied to the neck of the users.
I find this better than the people who try to build 3-tier sql dB driven apps for all those scenarios.
My estimate is that for every 20 “throwaway Excel,” only one becomes used heavily and required a painful redesign.
Trying to build all these correct from the start is actually inefficient because 1) you don’t know which 20 is right until quite a while in; 2) the idea that better requirements gathering and design is a myth as functionality and use is frequently, in my experience, new based on the spreadsheet and users don’t tell this to the design team; 3) the cost of properly designing all 20 is enormous so trying to pick only the most likely 5 is still expensive and has a decent probability of producing zero useful systems.
So while it sucks to be the engineer cleaning up some yahoo’s hack that got used by the CEO, I’m not sure what the solution is that is best for the enterprise.
What lots of people fail to understand is this: little work-saving apps seems to work magically (for the users) because a lot of the logic, especially how to handle thorny edge cases which nobody considered before, is left in the brain of the user himself.
If I designed an app where a particular use case would be handled by "write down the caller's number on a post-it note and then ask George from accounting over a coffee cup at the cafeteria" I would face the firing squad.
But ironically enough this is how the "little spreadsheet my cousin helped me with over the weekend" handles this case, and all other unanticipated cases, and this is great because it's not a 3-tier sql dB driven app. (An app that handles everything else, though, and has to meet also regulatory requirements including SOX).
I’m a software developer. I build big things, and I wrestle through rewrites of spaghetti Code. I once had to convert a start up from a cold fusion web site the ceo and biz dev (both non developers) had written. I get it.
But I think there are lots of little scripts and one-offs I write that are suitable for me, but would make so sense as a large designed system. Every once in a while they’ll get promoted or reused.
The solution to this problem isn’t premature optimization to write all my code with max generalization using on the enterprise approved development platform. But to just accept in life there are positive inefficiencies.
There’s also a decentralization argument here somewhere.
I'd like people that create "quick prototypes" and "just a throwaway excel with a few macros" realized that while they are valuably shortening the time to get something usable they are also shortening the time before their thing turns in a sort of albatross tied to the neck of the users.