501–510 of 590 posts
Earlier quoted context omitted.
Right. The big misconception is that really good programmers just write code at 10x the speed of bad ones. Nope, the complete opposite in fact.
And what does this mean now that AI can write at 10x this speed again...
The AI uses 10x the code 0.2x as powerfully. And code is a liability.
Earlier quoted context omitted.
In regards to (software) architects being regulated, the problem was always going to be that someone can jump in and build a "skyscraper" in their room/garage — and they have! I honestly have failed to see the value of anyone wearing an official "Software Architect" hat in my 20 years of being in or leading high performing software development teams: yes, we built and maintained complex systems with multi-team depend…
When I said it was showing my age, this is because I went to uni nearly 35 years ago. Back then, well pre-web, at a university that turned out chartered engineers who were on many of the same modules as we were, there was a consensus building that some areas of technology would be regulated to require chartered engineers. I was on an accredited degree course from the professional body who seemed sure, any time now, t…
However, I am currently in an enterprise org suffering from compliance/certification overhead while pretending that they do all of the good stuff topped with a highly infectious NIH syndrome (we build our own payment system, authentication system, wrap all the levels of cloud platforms and mobile platforms...). Trying to put more quality in gets opposition from... Quality Engineering, which is a separate department of people who've never written a line of code in their lives — because they need to be consulted and give a stamp of approval on any change, even if it's for the better :O We've got highly specialized roles of Software Architects, System Architects, System Engineers, Quality Engineering, System Validation, Software Validation, System Verification, Software Verification... It frequently becomes funny trying to make a single decision ;-) I don't have to imagine a world where something like this happens, because it exists in some enterprise orgs.
But the fact of life is that even in actual civil engineering, at every phase of building, there is a step of reviewing construction as it is built when constructions actually diverges from the project (happens quite a bit). Most of these get approved if they are not detrimental to the core function and structural integrity — this leaves the opportunity to contractors to actually do what makes more sense from their experience and still pass inspection.
This group of people would never understand that because they are mostly optimizing for appearing useful and invaluable, instead of for business or customer value.
Earlier quoted context omitted.
> Writing code is not hard. Writing correct code is. Knowing what is correct in a setting with paying customers generally involves interacting with those customers. That's like saying "building a car is not hard, building a real car that you can use and that passes regulation is". IOW, writing code is hard in every reasonable context.
I don't agree that "the coding was never the hard part" in general, but it is true at least often. For those cases where it is true, it is pretty much like your example, and the distinction is there in your example just like theirs. You supported their point.
Earlier quoted context omitted.
In which countries are Software Engineers not allowed to call themselves engineers unless they are professionally qualified engineers?
Before I retired (in the US) the organization I worked for was heavily civil engineering oriented, and they were pretty insistent that the computer folks not call themselves engineers. The state licensing board was pretty insistent too.
Earlier quoted context omitted.
This isn't true. I don't think you or me would want a car/TV/smartphone that's cheap and flashy but breaks every two weeks. Sometimes people are strapped for cash that's why they cheap out on stuff, or really are enthusiastic about it, so they tolerate it breaking all the time, but for everything else, reliability is king.
Nobody _wants_ it, but in practice if all cars/TVs/smartphones break every two weeks, what choice do people have? In tech, the era of competing based on quality is long gone. The winning strategy is to get a monopoly/oligopoly and then you can let the quality decay to zero and people will have no choice but to keep paying you money (or to your handful of equally-mediocre competitors).
Certainly not true for me. One example is Linux. I've been sticking with Ubuntu LTS, and delaying upgrades for as long as I can get away with for any system that's connected with earning or at least not losing money.
For the packages whose versions I care about, I compile them from source/use a PPA, and accept the consequences, but I really don't care for shiny features, if the price is random stuff breaking and having to be troubleshooted in the latest version.
Currently I'm reading the Software Wasteland and The Data-Centric Revolution books by software industry veteran Dave McComb [2],[3].
The books also addressed AI aspects but since it's published around 2018 before LLM, the information probably a bit dated on the issues. Hopefully the third book sequel in the trilogy can cover that aspect very well.
Some key takeaways from [2].
1) Almost all Enterprise Information Systems now cost vastly more to implement than they should
2) Most of the excess cost can be attributed to complexity
3) When you have hundreds or thousands of complex applications, you are completely stuck in what we call the Application Centric Quagmire
4) More large firms spend most of their IT budget on integration (without achieving more than ad hoc interfaces)
5) The fix is to become truly data-centric, where an integrated core model precedes the addition of functionality
References:
[1] A Tale of Two Projects:
https://www.semanticarts.com/a-tale-of-two-projects-healthca...
[2] Q&A on the Book Software Wasteland:
https://www.infoq.com/articles/book-review-software-wastelan...
[3] Software Wasteland and The Data-Centric Revolution:
Earlier quoted context omitted.
> but many details Which part of my list was just "a detail" to be dealt with at some point in the lifecycle (but only if you're not too busy shipping features) for you? You're laying bricks before knowing if the wall's supposed to be concrete. > Code is a form of low-level design and is where the rubber hits the road. Sure but in keeping with your analogy tires are fungible across most cars and it takes minutes to c…
In my experience, the parent's view and your view are an example of the divide between the Silicon Valley / startup mindset -- it doesn't need to last, it just needs to get us a paycheck so we can go on to the next paycheck -- and actual software engineering where people build resilient systems meant for humans to use for a long time. There's a conflation too that to approach things with this level of thought and car…
Iterative processes are state of the art. The RUP iterative lifecycle illustrates this nicely, with a big chunk of design in inception (first project phase), but also a non-trivial amount of implementation. The design & implementation flow in parallel in the next phases.
Earlier quoted context omitted.
> a sufficiently complex consumer or enterprise app winds up having big performance problems if people don't know what they're doing w.r.t. the code they write and how they connect systems together with that code. On those complex systems in particular the problems start long before any code is written. A software engineer can create and understand the specs, requirements, design the system, architectural decisions,…
I think most people who write code are the latter and not the former. The industry has diluted the term "engineer" so much that they maybe don't even realise that traditional engineering projects are about more than just implementation work.