3 ms·
In my experience, whenever user-developed software grows to achieve some kind of critical mass in a large company, it is nearly always discovered that the rapid
by NovemberWhiskey 5y ago
In my experience, whenever user-developed software grows to achieve some kind of critical mass in a large company, it is nearly always discovered that the rapid development and agility was achieved by a complete disregard for the kind of table-stakes engineering practices most take for granted.
Like: "Oh, you control changes to your massive Excel macro that Does The Thing by renaming the sheet and putting it on a shared drive, and it's never tested, and you have no idea who is using which versions of it, and hardcoded credentials for the database backend which running on your desktop which has no defined backup policy, and by the way also contains PII?"
- tyingq 5y agoThough I have seen user-developed software used the right way, I've also seen what you've described. Aside from the concerns you raise, there also a tendency for information to get siloed. Different areas of the business start hoarding data. And people start using the same term to describe different things, etc. The incentive to share and use common definitions is often lost.
- claytonjy 5y agoAs someone who hasn't seen user-developed software built the right way, I'm very curious to know what enabled such an outcome. What processes or infrastructure helped prevent the situation described in the parent comment?
- tyingq 5y agoI imagine there's other ways to do it, but the biggest difference was a sort of centralized visibility and watching the user-developed stuff as it evolved. Then interceding politely to get anything off fixed. Linking like tables, identifying who the authoritative source is, changing field names, providing some sort of discovery of what exists, pointing out data privacy issues, etc. Basically making sure there's a caretaker, and that they try to help and guide versus lock down and dictate, where practical.
- claytonjy 5y agoIs that "a" caretaker, or a team? From your first paragraph it sounds like an awful lot of oversight, to where this sort of "user developed software" is rather different in spirit from what we're generally describing with that term. Excel would lead to far fewer problems if you had a centralized "spreadsheet unification and QA" team overseeing all the spreadsheets...but then you'd see people opting out of that in order to move quickly, and the problem repeats itself.
- tyingq 5y ago>Is that "a" caretaker, or a team? Like anything else, the team size would vary, based on workload. As for Excel, it doesn't lend itself well to centralization. Lots of spreadsheets would float around on local drives, email, wouldn't have any simple inbuilt way to determine who is using them, how often, if they even exist, if they were ever going to be shared with more than one person, and so on.
- solarkraft 5y agoI expect that this is largely down to a fundamental UX mismatch of what's easy and what's not. You could probably "force" (encourage) some good practices rather easily by just making it easier to use them than to not use them. Backups would be a good example. This doesn't necessarily work for more complex things, but it seems to me (I am not very experienced with them) that a large part of these low code tools is exactly about making easy solutions like a hacked-up Excel sheet production-grade by doing the complex plumbing (like backups) for you.