The dream came true. In a modern non-software startup environment people often write code only as a last resort. I regularly see BizDev people setting up new business process automations with services like Zapier, Jira, Zoho, AutoPilot etc. There are plenty of CMS systems, customizable BPM, CRM, ERP etc where you can define UI and logic without writing a line of code and it just works. The cost reduction compared to the traditional coding is tremendous and enables small IT teams to run quite sophisticated businesses. Developers usually don’t see this, locked within their code-based programming paradigm, but this is already real.
Let me tell you, mostly these solutions suck. There are several reasons for this: (1) leaky abstraction, (2) not the correct abstraction, which works in all envisioned cases without limiting you, (3) often you do not want to only use an API, but instead change a tiny thing and that needs code or accept limitations (4) the existing API is weird or has a weirdly structured result (5) it is inefficient (6) you depend on a third party (7) you might have some rate limits, and probably more reasons.
If you got capable developers, let them do their job and create a flexible (expecting changes, simple design, usually not an elaborate many classes design) solution, that actually fits your situation. Developers are (should be) abstractions specialists. They should be able to find working ones in most cases.
Or live with limitations and the spread of thinking, that some things are not possible in various appartments. Mental barriers, that stop creative thinking, simply, because the tools do not exist.
Well, as a software engineer who wrote first line of code in 1991 and as a CTO of a medium sized company I would disagree here. These solutions do not suck. They work, they are cheap and they are efficient in addressing the business needs. You don’t always need a developer for simple automation, just like you don’t need a computer to calculate 2+2. Abstraction leaks, third party solutions and other things you mention are not the problems that always need a solution. Developers often overthink scalability and invest time in perfection of a code which will become obsolete in a year or two because of the change in the business model. It is there you can find the art of engineering: in finding the right problem to solve, rather than working on the problem for which you know a conventional solution. Zapier is unconventional, but it takes 30 minutes there for something that a development team would require a week or two. The limitations do exist, but it often takes some courage to understand that in your specific case you can ignore them.
They work, they are cheap and they are efficient in addressing the business needs.
In my experience, they are at most two of these things. Most of the time, I see lots of businesses bend over backwards to mold their processes to match the tooling they use, or expend lots of manual labour because their business flow isn't modelled efficiently in their tooling. Impedance mismatch is the #1 factor why many business automation projects end up costing multiples of what they were initially intended to save.
These problems aren't limited to off-the-shelf solutions, it could take an experienced developer months to really learn the business process and model it efficiently. Most businesses don't allow for that in their software budget, so you get either:
- something that works, and is relatively cheap, because it was cobbled together by someone from the business (see: excel sheets, access applications or nowadays, Microsoft Flow)
- something that works and is efficient, because it was built by a team of developers in close cooperation with the business
- something that's cheap and efficient but doesn't work, because it was built by a fly-by-night developer on a shoestring budget.
The only cases where you can have all three is when the business was built around a single piece of well-designed software, the CTO and CEO have been very conscientious about following the capabilities of the software, and the software manufacturer never decided to completely overhaul their interface for "reasons".
The biggest problem is that a lot of them are siloed, sometimes seemingly intentionally.
E.g. we have a bunch of stuff in Airtable. It's great. You can do amazing stuff with it, and it has a great API for most things.
Except for the change history and comments.
When you're aware of this, it is fine, but the moment your business processes start depending on using the comments and change history, you're locked in unless you're willing to use phantomjs or similar to log in and use the API (of course there is one) that their web client uses to access the comments, in a way that is a massive pain.
I'm happy for users to start building stuff and automating stuff. The bigger problem is when they don't design and don't understand the trade-offs. Often it works great for years, until it doesn't and you have a massive job untangling dependencies in some cobbled together solution.
Sometimes that is worth it.
Sometimes it causes you to incur costs far higher than what you saved initially because knowledge often gets lost as these system grow in complexity without any coherent thought behind them.
Very often, even if you end up using these tools, you'd still be far better off if there was still a review process to get someone to say "stop,if you do it this way you're creating a risky dependency, do it this way instead." Or to say "we really need the dev team to handle this."
It’s indeed a job of solution architect or CTO in smaller companies to do this review and develop a strategy telling, when something needs to be replaced by a custom code. Also it’s important to look at the costs not only in absolute values, but also relative to the IT budget. It’s ok to spend later 200K instead of 50K now if company revenue is going to be 10x higher or if your current budget is consumed by a more important project. Cost of money and resources can be different.
I think that's a bit harsh - a lot of these tools can be pretty powerful if they are used for the kinds of tasks that they are well suited for. However, stray into a task that is just that bit more complex than what they are good for and they can be an utter nightmare.
Of course, deciding whether a particular task is a good fit for a particular tool can itself be a tricky question.
Thanks for this! You are quite right. For the space that is dominated by "CRUD" apps there are quite a lot of alternative implementation pathways than pure coding.
And as most of the business value lives between the UI and the database, I understand why there is no driving incentive to create similar high quality tools for numerical, data intensive programming tasks that run on the customers desktop. We work in a niche, hence must be self sufficient.
IMHO, the business value lies in the data and the way they are structured. The user interface is important to the users, but the data are what make the business run longer than its users. Basically, without the data you can't provide the service; or worse, with bad quality data, you can't provide a good service.
I've spent (in bizdev, e-gov) tons of time figuring out badly structured data, fixing data quality issues, handling tons of administrative tasks to access sensitive data, etc.
I think it's up to a point where the structure of the databases actually influence the structure of the government. That's because nowadays, the databases and the business rules they embody are so complex that even the civil servants tend to forget how they work.
Sounds like a version of Conway's Law: "Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure."
The assumption was that the communications structure would come first and then the design would imitate it, but with really ossified hard-to-change systems it seems plausible that the departmental organization would shape around it.
> but the data are what make the business run longer than its users.
How often is that the case these days, though? Currently, when I subscribe to a service or buy a product tied to a service, I feel there's a 50/50 chance the company will shut down the service (or itself) while I'm still using it.
