I would say 75-85% of all client Jira tickets my team receives are actually errors in processing client business logic, not programming bugs. Sadly, all the little edge cases and special processing rules are the hardest to document and capture properly in the code itself because the rationale is paragraphs long and often only makes sense when the product manager explains it.
I'm not sure if anyone has ever written about the problem with the staff being less committed than the software.<p>It is easy for me to make some big long-lasting decision about something that gets encoded in software and then I can leave next year and everyone else has to live with that decision.<p>I don't know how to solve that unless you write software to be hyper-modular and able to be modified without a complete rewrite of everything. Either that or keep it simple, build it quickly and throw it away after 2 years when everything needs to change.
Is like the old proverb about software: Is far easier to build an OS than an ERP system.<p>I do this for life, and kind of <i>like it</i>. I like working on data manipulation and enjoy using relational databases and the others too.<p>Business app allow you to face EVERYTHING that make you giggle as a developer.<p>Is Monday doing stuff, nice web app, At 1:00Ppm the sky is falling and suddenly you need to port it to iOS/Android.<p>Also the app was invoicing and now is half-debt collector with Uber-like geo support.<p>FUUUUUUNNNNNN!
I came in to rewrite software that runs a warehouse. The old software, was half working but used for 10+ years, the source code provided was different than what was in production(original dev lost it LOL).<p>As I decompiled the production version and met with managers to learn/document the process. I quickly learned that nobody knew the process. There were pieces of information in people's head, and in several old apps. However, nobody clearly understood the process, where the data is exactly stored or how the data flows.<p>The app took more than a year to write but could have been written in 2-3 months if previous projects had decent documentation.<p>To develop an app for an enterprise you really need managers to be on board, otherwise, the new app will suck just a bit less than the one it is replacing. There are politics involved and petty arguments. Many people are just unhappy at their jobs and it leaks into their work.
Is this why Salesforce is so successful? It gives you a million enterprisey features (ad hoc reporting, role based access control, single sign on, user management, field level compliance) out of the box even if you’re managing a glorified spreadsheet?
I have always wondered why reporting was always so complicated and broken in every company I worked with. By reporting I mean "I spent two days on this project, five on that one and took a day off, I also had to drive 50 km to the the customer's site so that's an expense.". Then I realized a <i>lot</i> was happening behind the scene, some of them being legal requirements with hefty fines if not done right. And all companies are different.<p>And even though we have all these tools, I am impressed by how much tedious manual work is still done. For example, our poor assistant manager has to check that every expense is tied to the correct project, and the tools does nothing to help her (or us for that matter).
Didn't read the article, but totally agree with the title. Having seen the level of complexity the business-side people (analysts, managers, product owners) have to deal with on a daily basis, I'll gladly work on our ridiculously overengineered k8s-based web app. It still seemed rather sane compared to the business side of bank.
It's three good years now that I am consulting at a firm as a link between the company and ERP provider. At the time the presented problem was 'the ERP doesn't work'.
Today the majority of the issues are resolved and it's pretty clear that the problem was the process, not the ERP (which, btw is far from perfect).
My job is something between understanding and fixing the process plus reducing the software customisation requests.
On top of that, just add your typical ERP with totally counter intuitive UIs and a bunch of users with an overall general aversion to changes.<p>I love my job btw.<p>(I've not read the article, but I like the topic and felt like to drop this comment).
I think it’s because enterprise architecture is taught and practiced as “architecture of software in a complex environment” rather than “architecture of a complex organization containing people and software “. A complex system with no architecture governance and rampant complexity cannot function sensibly and mr. Conway tells us there is a homomorphism between software and organization. I have been earnestly trying to fix this with an EA course I teach but the going is slow.
Sometimes the demands feel like they are just bulletpoints added to make sure the specification document was long enough so it looks like they did some work.