This x1000! I took on a freelance project for a heavy machinery hauling company. They were a year into transitioning away from some customized off the shelf Enterprise scheduling and dispatch system into some custom built software by an “Enterprise” consulting company.
They were originally bringing me in to audit what the team that was building it but that pretty much changed on the day I submitted my proposal...
In the proposal I wrote to my then prospective client I allocated a couple of days of onsite interviews with “lower than management” people that would be using the system or it’s outputs, and a week of shadowing people in all roles that would be directly using the system. The project sponsor (to his credit) didn’t ask me why I would need to do that, he started laughing and exclaimed that I was the only person to ever even recommend this approach.
We ended up re-writing the proposal into multiple phases where I just interviewed and assessed, documented their current processes, provided business process workflows and suggested ways their current workflow could be optimized, irrespective of any one technological solution. A crappy process, then automated, is still crappy.
I wound up spending 6 weeks before even proposing anything that had to do with technology.
My implementation proposal was set in phases that would bring related functions to light in a way that their teams could begin using them right away and we could collect feedback and iterate while producing the next set of features as well. It was their first ‘agile’ project or contract and the fear was quelled when after the first month I had put more useful software in their dispatchers hands than the “Enterprise” team had in a year.
From day one interviews to “finished” project we spent about 6 months and that system still lives 9 years later- though it has been modernized and upgraded every so often in the intervening time, it is still one of my proudest projects even though it was one of the least “sexy” I’ve ever done.
> it is still one of my proudest projects even though it was one of the least “sexy” I’ve ever done.
I think one of the most valuable thing software engineers can do for themselves in some circumstances is attempt to shift perspective towards assessing projects by how many people they help and how. The most rewarding projects I can think of are the ones where a day or two after rolling them out, I'm contacted by a few employees that they affected the most and told they love it and it saves them 30-90 minutes every day, consistently.
I think it's a feeling most developers can empathize with, since we often automate boring drudge work in our own jobs and lives. Making multiple people's lives and jobs a little less monotonous and dreary, or a little more effective at their job in a way they feel and appreciate is a good feeling.
My wife is a genetic counsellor, and as part of her work she regular has to use this one formula to calculate the probability of this one genetic condition I can't quite recall.
Because of the complexity and the importance of getting it right, it took her around 10-15 minutes every time she needed to use it. She, and her colleagues, are pretty much luddites so a basic calculator was their only tool.
I spent 10 minutes writing the formula in javascript, dropping it an html file, and running a few test.
She absolutely loved it, and shared it with the rest of the staff. Apparently some counsellors at another clinic heard about it and requested it as well. Someone thanked me at her Christmas staff party.
In terms of effort to build vs. hours saved and end user appreciation, I don't think I'll ever top it.
It probably boggles the mind of people like us, used to being power command-line users and automating our boring tasks with powerful tools, to hear stories like this.
With the prevalence of office jobs that use computers, being a developer is sort of like being an engineer in the 1960's or before but having the ability to whip up designs for simple mechanical devices that you can build for very low time and money cost, and replicate for free. It's like being the inventor of the slap-chop except that it costs so little to get items out there, that people often just do it for free. I would love it if I was doing some annoying repetitive task like mincing garlic or onions and someone said "hey, I can make that easier. Give me an hour..."
I like your description, it's one of things I love about software, how malleable it is for quickly building "devices", tools for my own use or a potentially large number of users.
About the last point you made, how it would be great if hardware/mechanical devices could be made more like software - a few years ago I heard about "micro factories" (forgot the exact term): 3D printers for small(er) scale manufacturing. It seemed promising that soon we could be writing software to manufacture devices/products at home, in a garage, local maker "lab". If you thought of an easier mechanism to mince garlic, you could whip up a prototype in a code editor and "print out" a working prototype (or production-level device)..
One of my best work hackathons was spent asking non-technical people what parts of their job sucked, and helping them automate those tasks. The last project involved updating a button that cloned data to go further, and clone some additional data. That work took me an hour, but saved a team at least 10 hours every month!
You did the work of a product manager, business analyst, and engineer all in one. This is what consulting is supposed to be but most companies are merely hiring contractors and are uninterested in any challenges to their requirements (that were never derived from the real world in any way, just an ivory tower of management / conceptual consultants). So you also had a good client as well that respected your proposal and were willing to re-assess their assumptions.
I had a fantastic client. I don’t know if it’s because the rigging industry is full of “holy sh, we gotta think on our feet” situations or what, but for a seemingly “low tech” client they grasped on to an iterative and flexible approach so much better than most clients I’ve ever had from the tech industry.
Yep, most clients aren't interested in _paying_ for it. "I wound up spending 6 weeks before even proposing anything that had to do with technology." And they start paying without knowing exactly how long/how much money it will take to get to the end, or even what the end is.
Penny wise pound foolish.
To be fair, they may not _trust_ that you'll actually do a _good job_. There are so many terrible consultants out there, and clients are not very good at evaluating who's going to be good.
RE: and suggested ways their current workflow could be optimized, irrespective of any one technological solution. A crappy process, then automated, is still crappy.
One has to be careful with this; often a process has "invisible benefits" such that outright removing it creates unintended consequences. For example, one industrial analyst found a way to speed up the assembly process. However, it was so efficient that the glue didn't have time to dry before the subsequent steps, damaging the product. Work-arounds were found, but it took time to iron out all the changes.
My first paid gig I did this with wild success also. After that I tried to do this several times and was always met with incredulity. Management never seemed to grok the importance of this, to the point where I started thinking maybe my first experience had been a fluke (gaslighting). While I no longer think this is practical (unless you are the one in charge), I do recommend it whenever possible. The product will be orders of magnitude better, but expect management to strain at the gnat of paying a software developer to watch a non-technical person do their job.
You could manage this by setting expectations early. When you start negotiating, a classic trick is to set a few different “packages” and then gently guiding the other side towards the option you really wanted from the start.
So let’s say you really want to do this bit, but you also know management is too cheap; you create a super-cheap option where you don’t do the activity, but something else also happens that management is unwilling to accept, something pretty horrible. Then you have two other packages that are actually desirable, both containing the activity; one of them should be the bells&whistles option that will look expensive. Management will discard the costly choice and the obviously-subpar one, and pick the middle tier. The skill is in not making it too obvious that is what you wanted all along - i.e. you should sound really disappointed that they didn’t pick the super-expensive version.
Loved the story. I'm studying (mainly web) software development right now, but this type of work is what I enjoy most. Studying & understanding users' workflow and building a solution that does exactly what they need.
Do you have any tips/ideas on how can I pursue this as a career?
This x1000! I took on a freelance project for a heavy machinery hauling company. They were a year into transitioning away from some customized off the shelf Enterprise scheduling and dispatch system into some custom built software by an “Enterprise” consulting company.
They were originally bringing me in to audit what the team that was building it but that pretty much changed on the day I submitted my proposal...
In the proposal I wrote to my then prospective client I allocated a couple of days of onsite interviews with “lower than management” people that would be using the system or it’s outputs, and a week of shadowing people in all roles that would be directly using the system. The project sponsor (to his credit) didn’t ask me why I would need to do that, he started laughing and exclaimed that I was the only person to ever even recommend this approach.
We ended up re-writing the proposal into multiple phases where I just interviewed and assessed, documented their current processes, provided business process workflows and suggested ways their current workflow could be optimized, irrespective of any one technological solution. A crappy process, then automated, is still crappy.
I wound up spending 6 weeks before even proposing anything that had to do with technology.
My implementation proposal was set in phases that would bring related functions to light in a way that their teams could begin using them right away and we could collect feedback and iterate while producing the next set of features as well. It was their first ‘agile’ project or contract and the fear was quelled when after the first month I had put more useful software in their dispatchers hands than the “Enterprise” team had in a year.
From day one interviews to “finished” project we spent about 6 months and that system still lives 9 years later- though it has been modernized and upgraded every so often in the intervening time, it is still one of my proudest projects even though it was one of the least “sexy” I’ve ever done.