> Took me an afternoon to write a simple C# tool to ingest a number of files and spit out the data that she needed. She had been waiting over a year for my software team to get the go-ahead to do it as a built-in feature.
The counter to this is that this tool now has no support (which may be fine depending on the tool).
I remember my first job which was 30% SW and 70% other engineering. We wrote a few tools to automate stuff that our customers used.
One of our customers came to my manager and told us he had a tool we wrote over 5 years prior. It was a small Perl script. Their data source had changed formatting a bit and now the script no longer worked. They wanted us to update the script. Several hours were spent between the two teams arguing. My manager did not want to own it. He said he had no record of it, and none of the people on his team had any memory of it. We did not own it. They kept insisting "One of the engineers in your team (who had since left the company) wrote it, so you own it!"
I pointed out to the coworker that the request was so trivial we could have solved it in under an hour, and the company had lost more money by arguing. The counter was "If we fix it, they'll keep coming back to us and in the long run more money would be lost."
Over the years, I've realized how right he is.
I do occasionally write simple scripts to help our customers, but management always makes it clear to them that this is an unsupported prototype, and the customer needs to maintain it.
And that's a perfectly valid rebuttal. Over time, she occasionally asked for more features, and I obliged as time permitted. The requests were always reasonable, and I checked the source into our generic "Tools" repository in case someone else ever took it over.
The bigger problem I saw was the shortsightedness of the organization. The software group had a history of writing small test tools for other groups, but no one ever considered listening to what she was asking for and checking if there was another way of getting the data besides changing the Product itself. It's always easier to just say No, even when there's a clear benefit to someone else.
> Just bill for it, support and all. Make the customer say no. Or if they're willing to pay then great.
This is probably the best solution. The organization still has to be prepared that business users will make their own tools, though. And they will frequently get things wrong, because they’re not developers.
"Past outcomes are not indicative of future results" Just because they came back after 5 years doesn't mean it will be 5 years before they come back again. It was, in fact, quite unpredictable. We didn't want to be on the hook every time their data source changed the format of the data. If this work is so important, they need to work with the team pumping out the data to have it standardized and stable.
This was in an org that was sorely lacking programming talent, and management clearly did not want to hire SW engineers. There was always a lot more work than there were engineers for, so it was a continuous battle of demarcating boundaries. If you start doing SW favors, everyone will want it from you, and will push the upper managers to force you (or your team) to do it. None of this will matter for promotions, because SW was secondary to our jobs. Without a hard stance, you'll drown.
As another commenter said, it was an incentives problem. Right or wrong, good or bad, helping people with small scripts was not something that would ever be rewarded.
It was also a matter of principle: If you do someone a favor, and they come back to you with an attitude and insist you owe them because you did them a favor, you stop doing those favors for them. That was something I would see often in that org (even outside of SW work): If you do work for someone, they expect you to own it.
Overall, the culture was poor. But I've found elements of it in most jobs.
Judging from the comments, it's evident I wasn't clear enough: When I said "our customer", I did not mean an external customer, but an internal team. We were a service/expertise department that helped various teams in the company with our expertise (and the expertise was not software). This was all informal - there was no monetary accounting/SLAs for our services.
> As another commenter said, it was an incentives problem. Right or wrong, good or bad, helping people with small scripts was not something that would ever be rewarded.
I agree with you here. The long queues for internal dev support is indicative of high demand for that support. If the organization can’t or won’t staff properly to provide that support, both the users AND the devs are forced to make tough choices.
So the devs say “No” to requests (or it takes an inordinately long time to get done), and so the business users make their own tools.
I've been in that role. It's utterly thankless. You will experience every way that the devs and non-devs can't work together. The devs will treat you like a scab. You'll discover all of the non-technical reasons why it's hard to be a dev, without being paid like one.
Today, my rule is that I only code for myself, and share my code with others who are also good coders. I'll use code to produce a result and share the result. This also lets me off the hook from all sorts of things like UI's, installers, etc.
Anybody who's a good enough dev to do it for money, and can stand doing it, should be.
Edit: Thinking about it more, it's not that we can't work together as people but that the organizational culture makes it hard.
While I agree in principal, speaking as someone who's been that person it creates a lot of stress when it's just one person. You never get a break from enhancing or fixing and maintaining the tools that the rest of the team is using, and probably lose opportunities in your "other" skills. You'll probably get no support from the actual dev groups in the company, never get funding to hire a contractor (which almost never works out anyway), potentially end up stuck career wise because if the tools are really useful your manager isn't gonna want to lose you to a promotion.
A small "tools" team shared across some related disciplines under common leadership would be more ideal in my experience, but normally it's either beg for the real dev teams scraps or go rogue.
I like using code to solve problems and automate things, but I have no desire to be a full time coder just like I don't have a strong desire to be a people manager.
I’ve been in that role and it’s incredibly rewarding. The satisfaction from delivering something valuable to the sales leaders I partner with when they get something they genuinely appreciate trumps any commit dashboard.
What's the counter? You could have effectively no support either way, only this way you at least have a working (perl) script
The long argument is also pretty flawed without any cost estimates, like, maybe they'd come to your every 5 years for a hour worth of work, but then looking up history and arguing about it takes longer
Not to mention this discounts the human cost. Marketers who have to wait 9 months to get anything done, and are forbidden from doing work themselves, realize the company doesn't actually care about accomplishing things and the passion dies. Why bother trying to come up with new and innovative things to test that could move the needle if its a kafkaesque nightmare every time?
I guess there's a different though - if its for a customer then its potentially something that you should be charging for. If the "customer" is actually another department in your company and the automation helps then the company should have software devs allocated to internal tools - they'll probably find a lot more places to smooth things out if they're allowed to look.
> Then the same people that wouldn’t help say, “Why did you build this monstrosity it Excel/Access/$OtherNoCodeTool ?!”
Not me :-) If Excel solves your problem, go for it. If it becomes a monstrosity and a bottleneck, then their management needs to allocate proper resources (i.e. hire their own devs). And they often do. The ones we see are the leftovers, where the ROI for a highly paid dev doesn't exist, so it's more economical to stick with the monstrosity.
The counter to this is that this tool now has no support (which may be fine depending on the tool).
I remember my first job which was 30% SW and 70% other engineering. We wrote a few tools to automate stuff that our customers used.
One of our customers came to my manager and told us he had a tool we wrote over 5 years prior. It was a small Perl script. Their data source had changed formatting a bit and now the script no longer worked. They wanted us to update the script. Several hours were spent between the two teams arguing. My manager did not want to own it. He said he had no record of it, and none of the people on his team had any memory of it. We did not own it. They kept insisting "One of the engineers in your team (who had since left the company) wrote it, so you own it!"
I pointed out to the coworker that the request was so trivial we could have solved it in under an hour, and the company had lost more money by arguing. The counter was "If we fix it, they'll keep coming back to us and in the long run more money would be lost."
Over the years, I've realized how right he is.
I do occasionally write simple scripts to help our customers, but management always makes it clear to them that this is an unsupported prototype, and the customer needs to maintain it.