[prof_hobart]

On the opposite site of the coin, I was a professional developer 25 years ago (and still keep my hand in as a hobby), and do regularly struggle to understand why things take as long as they do these days. We were quoted a day for something that I said could be written in about half an hour - their quote included nothing more than coding and unit testing it.

So I was challenged to prove it. Which I did (or rather I did it in 10 minutes). When their code came back, a day later, it didn't actually work. When we pointed that out to them, they came back another day later with code that looked almost identical to the one I'd written in 10 minutes.

tl;dr. Sometimes managers don't realise the complexity of modern software, but sometimes modern developers are actually just plain slow.

[huherto]

I have been developing software for 20 years and I am currently replacing some applications that were written in the last five years. They use OOP, patterns and the latest tools. Often I wade through dozens of lines of codes trying to find the meat of what they are trying to do. I usually find easier and shorter ways to implement the same thing just by better design and avoiding repetition. I don't think programming is just about the tools, I think it is about structure and organization.

Every pattern, layer, feature or tool that you introduce in a project, makes it more complex, so you really have to use good judgment when you decide what to add.

[prof_hobart]

>Every pattern, layer, feature or tool that you introduce in a project, makes it more complex,

That really shouldn't be true.

A pattern is simply a commonly used way of solving a common problem. If you're picking one that make it more complex, then you've picked the wrong pattern. The reason that I could do the example I talked about in my original post in 10 minutes was because it was a bog-standard design pattern designed to solve exactly the issue that the software needed. Amongst the many reasons why it took the developer 2 days was the fact that they had to pretty much reinvent this pattern from first principles.

Equally, if you're introducing a tool that doesn't simplify something that you'd need to do/build manually then you shouldn't be introducing that tool.

[bpyne]

Times have changed considerably. When I started in the industry 20+ years ago our tools were a compiler, debugger, and editor. Any library not provided by the compiler we wrote simply because purchasing libraries was very expensive. We also weren't afraid to code a solution specific to the problem and not be overly concerned with abstracting every library for potential use with any future application. Most work went into the server code, which housed the application logic and coordinated with the database; graphic UI's were a luxury.

Nowadays a web application, for example, is tiered more. Different frameworks are encouraged for the different tiers: Bootstrap, Spring, Hibernate, etc. Each one is its own ecosystem and is built on top of other libraries. It's very common to make web service calls outside your WAN. Quickly you find out that "standards" have different interpretations by different library authors.

UI's are no longer an afterthought. They affect how successful your application is. (My observation is that a well-designed UI can cut down on user errors and training by two thirds over a merely functional UI.)

I'm keeping the example simple by not mentioning necessary middle-tier components that we didn't use 20+ years ago. We also didn't worry about clustered environments, asynchronicity, or concurrency.

Not knowing the application you needed or how the analysis was done by the coding team, it's hard to say if some of their "slowness" was getting to know the problem AND coming to understand how extensible, performant, and reliable you wanted it. My own approach is usually to solve the "happy path" first and then start surrounding it with "what if's" - e.g. what if a null is passed into the function, etc. Over time I refactor and build in reliability and extensibility. The coding team you referred to may have used a different approach in which they tried abstracting use-cases and building an error handling model before solving the "happy path".

Your "tl;dr" is spot on. But I'd like to raise a cautionary flag about judging modern development through a 25 yo lens. The game has changed.

[prof_hobart]

I'm still heavily involved in IT. I know the game has changed. As well as the complexity that's come in to it, there's an awful lot of complexity that's disappeared. Those necessary middle-tier components and UI frameworks have to be used, but they no longer have to be built from scratch.

>We also didn't worry about clustered environments, asynchronicity, or concurrency.

Clustered environments, probably not. But asynchronicity and concurrency were the bane of my life. Writing comms software back in the day involved having to hand-craft both the interrupt-driven reading of data from the i/o port and the storage and tracking of that data in a memory-constrained queue, synchronised with displaying that data on the screen. And the windowed UI had to be hand-crafted as well. Error handling was no more of an afterthought then than it is now - and you couldn't roll out a patch for a minor defect without manually copying 500 floppy disks and posting them to clients.

I understand why some bits of development take a long time, but the reality is that 90+% of the development work that our place does these days is what an ex-manager used to refer to as "bricklaying" - dull and repetitive work that involves pretty much zero thought to implement. Extract file X (using the language's built in drag and drop file-extract wizard), sort it by date (using the language's built-in sort module), split into two separate files (using the language's built-in file split module) and load into database Y (using the language's built-in database load module).

And even with all of these tools, it still takes 10 times longer for people to develop these kinds of thing than it did when we were writing all of this from scratch. It's not because of complexity of coding, of environments, or of frameworks. The problem is that much of the IT industry has replaced skill and knowledge with process, contracts, documentation and disinterested cheap labour.