Secondly, you can't know he hasn't worked on mature systems (he didn't say). Most people learn by working with a variety of systems that are at different stages (greenfield to twilight), and more importantly with different quality (poor versus good architecture/systems/teams).
A long period working on one good system may help a few people learn, but from what I have seen, it often doesn't (I have worked with crap programmers on mature systems).
Hopefully GP answers for themselves.
https://www.joelonsoftware.com/2001/07/21/good-software-take...
Sure a CRUD MVP can be cranked out in six months or less, but that's not what we're talking about.
Photoshop is an example of a product that still maintains its market fit after decades, and why folks complain about alternatives.
The part I disagree with is the idea that you get to done. Photoshop is a great example. It's over 30 years old. Would Photoshop still hold its market position if it reached maturity 20 years ago and said "we're done?" Ignore UI changes and support for new OSes for a second. Would Photoshop be the market leader without Camera RAW support? High Dynamic Range? GPU acceleration?
Just look at Photoshop's version history:
http://en.wikipedia.org/wiki/Adobe_Photoshop_version_history
You don't have to agree with every change they've made, but there's a lot of serious features that got released after Year 10 that are need-to-have features. I don't think Photoshop 5.5 was the last Photoshop professionals needed.
Meanwhile, Affinity Photo is only four years old, and while if you had to choose between them Photoshop still has a lot of things Affinity doesn't, I'd pick it over Photoshop 5.5 in a heartbeat.
> So, it takes a long time to write a good program, but when it’s done, it’s done. Oh sure, you can crank out a new version every year or two, trying to get the upgrade revenues, but eventually people will ask: “why fix what ain’t broken?”
Just because you've been working on shit show projects that doesn't mean all projects are mismanaged like that.
Billions of in-house apps, for companies > ten years old.
The link above details several more, read it.
P.S. Gnaritas, you're dead. Tried vouching, didn't work.
Plenty of companies aren't attracted to the new shiny.
So you've never worked in good code, that's all. Most of the world runs on software evolved over greater than 10 years. Everything you said is wrong, because you've been surfing trendy crap that businesses mostly ignore. Good architects don't use immature languages that might not be around in 10 years, they're smarter than that.
Btw. The supplier was one of the leading and most hip e-commerce (consulting) companies in my country.
I've seen and been in involved with others too by all kinds of companies. They are everywhere.
People changing jobs/teams faster than that may simply never experience a feedback cycle on the real, long-term quality of their work.
That is quite different than the CRUD web application that most people are working with.
This is what differentiates as a startup from a real company.
1. Are you sure that the person writing the blog post is the person in charge of webhosting?
2. I have pet projects running on some small virtual private servers. I have no idea if they could handle the load from HN. Does it make me a worse software engineer that I can't justify paying more for a beefier dedicated server right now?
PS: does someone have an estimate of how much traffic (hits per minute/hour) the HN front page can bring?
(he got 20K/day, which for all intent equals zero in my experience)
You do understand that this is cmu.edu, and the blog post is probably written by a CS prof who has nothing to do with CMU's basic IT operations.
If our "Software engineering leaders" cannot handle simple tasks, what does it say about our profession?
It says that they have more important problems to be working on than managing their university's web-servers, which a CS undergrad could do.
I find it hilarious.
They’re so busy with their “more important” issues, that the whole thing fails in practice.
If they truly had organizational wisdom we could utilize, why don’t they deploy it themselves, to keep their website online during small spikes in traffic?
If their work can’t even be applied to their own organization successfully, why should we believe it will be successful elsewhere?
“Physician, heal thyself.”
This is such a weak argument. Where did you hear that their principles were not being applied in real life? Why do you automatically assume the university's website is built on their principles? This entire discussion is trivial.
A _good_ software architect is almost the exact opposite. She's a minesweeper, finding obstacles that would have caused re-work and scope change. She untangles the business requirements so that expectations can be clearly set and communicated. She does research on existing approaches to the problem, becomes acquainted with the relevant open source work and thereby serves as a check against "not invented here" syndrome. If this some of this ends up being best delivered in a document or a diagram, so be it, but the point is to enable the developers, not a masturbatory exercise in self-indulgence.
Who is responsible for understanding the interconnections of a system when there are over 100 engineers? That's the architect.
C'mon, this is a university's website, and the author of the original piece is just a user of that website's CMS, not its architect.
Depends on a type of project and many other factors. If you're say building a business app for a client delegating architecture decisions to individual devs on "as-needed" bases means either that all members of team need to be equally capable, have an excellent understanding of client's business and very clear and uniform vision of bigger picture where project is going - or more commonly that you'll end up with a terrible, suboptimal mess of different approaches and interpretations of requirements. Also you usually don't want to pay 10 expensive devs to study the client's business and specifications for days or weeks, when you can have just one do it and propose the solutions to others. So you need a person in charge, and you need that person to know how to do it good, because not everyone, even senior devs, is equally capable of tracking all the moving parts and envisioning the optimal solution. It's a job for someone who's good at it, and you can call them architect or tech lead or whatever, title doesn't matter, but letting them be focused on global picture instead of doing little isolated tasks with everyone else will save you a lot of headache.
However, I totally agree with you that often people hired to do that are not really good at it, just like a lot of managers are not very good in managing projects (and many devs are not very good in programming I guess). The problem there is not with the role itself, but HR and the organization.
You're describing a problem caused by developers, who for some reason ignore the architecture that they are supposed to adhere to.
As yet another data point, the website cannot handle Saturday HN front page traffic. How can "Principal Systems Engineer" meaningfully talk about such complex matters of system design and architecture, when they fail at much easier task of handling web page availability with a slightly non-trivial load?
EDIT: A few people mentioned that it would be incorrect to use `HN hug of death` as an example of author incompetence, since it was just some random university or institute. I was about to agree, but then I checked the website, which proudly stated: "The SEI: The Leader in Software Engineering and Cybersecurity". From my perspective, if you claim a thing like this, you definitely should be able to handle a minor spike in traffic.
Now, it also might be that author has nothing to do with the organization and hence not responsible for the website performance. However, this is also not true: "<AUTHOR> is a senior member of the technical staff and Principal Systems Engineer at the SEI...", as stated on their bio page. To me this either shows little ownership or little understanding of underlying resources the author relies on, which serves as another proxy of their actual architecture skills.