3 ms·
I don’t know what is going on with this article. The first half is a maybe reasonable description of a common way for certain kinds of contracts to go wrong. Bu
by dan-robertson 3y ago
I don’t know what is going on with this article. The first half is a maybe reasonable description of a common way for certain kinds of contracts to go wrong. But obviously lots of software doesn’t get developed in this sort of arms-length way. I would say that imaginary problems (as the author defines them) cause failed projects by consultants/contractors.
I find the rest of the article to be bizarre. The discussion around retail banking software seems unacceptably incurious and a very likely incorrect diagnosis of the cause of the problems (it basically stoops to an ‘I could do that in a weekend’ level of criticism[1]). It then transitions to a screed about Goldman Sachs which is, as far as I can tell irrelevant (Goldman do very little retail banking; their software development will be quite different to that done for retail banking), and then some description of how the author thinks (all?) large companies are (mis)run. I don’t know if Goldman was meant to be a prototype for this model of company management but it seems like a particularly strange example (in particular, they still will have some remnants from the culture of being a partnership, so they’ll be run somewhat differently from other big investment banks).
I found the second half did not ring true. I’m sure software projects fail at big companies (including retail banks, Goldman Sachs, other investment banks, tech companies, and so on) but I don’t find the reasons given in the article convincing to the extent that I think that section could have been written by someone who had only ever worked at very small companies. But maybe it’s just me and most companies are so obviously terribly wrong in these ways that no one even bothers to write about them and so I only see subtle ways they go wrong like projects dying off due to management acting in bad-faith ways or rewarding people for things that aren’t actually so good for the company or whatever.
If you’re interested in better discourse around certain kinds of bureaucracy, look into moral mazes.
[1] generally ‘I could do that in a weekend’ is code for ‘I could do some minimum thing that doesn’t actually solve whatever the important problems are in a weekend’
- mlhpdx 3y agoThe second part might be summarized as “when technology starts to diverge from the business model, or vice versa, both become messy.”
- chrisco255 3y agoYeah I agree the author got a bit dismissive about the inherent complexity of solving business problems on an ongoing basis. He even links to a Wikipedia article about Google and offhandedly claims that the problem of indexing the whole web was solved by a couple of guys. We all know Sergey and Larry created the original Pagerank algorithm, but it's farcical to believe that their original algorithm would have stood the test of time without input from hundreds of engineers who had to deal with the rapidly evolving web and all the ensuing SEO spam, ad scams, revenge porn, illegal content, international firewalls, international regulations, scaling their infrastructure to handle billions of requests, creating an ad network to support the endeavor, etc etc. That all cannot be done by two guys in a dorm room. I'm sure Google as an org has accrued plenty of staff that are working on mild to non important tasks over the years, and I get where he's coming from, but reality is far more nuanced.
- angarg12 3y agoThe second part of the article makes it clear that the author has never worked in online banking (I have), and possibly any other complex domain. > Have you ever heard about those three web engineers who figured out that secure online banking is actually quite an easy problem to solve? > The storage and transfer of numbers is not a particularly hard problem. These quotes are so incredibly disingenuous that make me question any advice OP has to offer. First, banking is quite a complex domain, and it's complexity increases exponentially with the kind of services that you offer. Second, banking is a highly regulated industry, which makes everything why harder than "it should". In fact many "neobanks" have appeared in the last decade, and this is usually their biggest hurdle. Third, online banking needs to deal with quite a few hard technical challenges. That's why the likes of Monzo, Starling or Revolut often given tech talks. So no, imaginary requirements weren't the root cause of bad software when I worked in banking. A 20+ years old big ball of mud, inability to pay off any tech debt (unless you wanted to get literally yelled at in front of the entire team), flaky and severely insufficient tests, and a very toxic working environment were all causes of bad software.
- dan-robertson 3y agoYeah I deliberately didn’t want to write that much about the retail banking stuff because I don’t know why it is the way it is (though there are a few reasons to guess). People would often give regulations/compliance as an excuse for eg not being able to set up an account online, but then the pando happened and somehow this stopped being such a problem. I feel like either those people were just not knowledgeable about the reasons, or they were rationalising business reasons for the bank to not do those things.