7 years and 4 different companies is why your perspective is skewed. You’ve never seen a system mature at that job change rate. Therefore you have never really had to deal with decisions that impact long term which is where architecture matters.
Everyone is their own worst critic. I frequently am editing production code I wrote 15+ years ago. I also have to deal with the unintended consequences or side effects from my code that were not thought out at the time. It certainly is hard to teach this kind of thing and, more importantly, find a way to get people who haven’t experienced it to find the value in doing so.
Pretty accurate. And if you ever get asked "why do we have to do that useless thing you said?" and you reply using expressions like "futureproofing" or "anticipation", eyes might get rolled at you and you might even get management to disagree for the sake of tight deadlines or yagni.
Firstly, he said he has never worked with an effective architect: you have changed his meaning completely to imply he doesn't think architecture matters.
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).
I don't actually think that aged very well. Joel's company has been renamed after a product that's two years old, and his mature product has been fading in the market as newer alternatives like Jira and Asana and (ironically) Trello take over its market share.
Building mature software can take a long time, I agree. It depends a lot on the complexity (an operating system is obviously more complex than a solitaire game).
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?
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.
> But that’s just the first ten years. After that, nobody can think of a single feature that they really need. Is there anything you need that Excel 2000 or Windows 2000 doesn’t already do? With all due respect to my friends on the Office team, I can’t help but feel that there hasn’t been a useful new feature in Office since about 1995. Many of the so-called “features” added since then, like the reviled ex-paperclip and auto-document-mangling, are just annoyances and O’Reilly is doing a nice business selling books telling you how to turn them off.
> 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?”
Seriously, who works on a piece of software for 10+ years? Usually within 2-3 years one has to throw away most of the code as it was written in an obscure, low adoption language, or it is just so difficult to maintain that new features can't be added. Except for SOA or mSOA where parts can be replaced at any time.
> Usually within 2-3 years one has to throw away most of the code as it was written in an obscure, low adoption language, or it is just so difficult to maintain that new features can't be added.
Just because you've been working on shit show projects that doesn't mean all projects are mismanaged like that.
Please put in a bit of effort. Off the top of my head, Postgres, Office, Qt. In yesterday's Blender thread they discussed it and Maya, Autocad, 3DS Max. Web? Jquery, Drupal, Wordpress.
Billions of in-house apps, for companies > ten years old.
> Usually within 2-3 years one has to throw away most of the code as it was written in an obscure, low adoption language, or it is just so difficult to maintain that new features can't be added.
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.
I've come in to an "agile" (whatever that means in practice) project one year into it's life as a project manager (on the customer side), forcing it in to production after prioritizing all critical things (taking an additional year). It was an e-commerce website built on a standard platform.
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.
Business requirements evolve. Even if you ship a working and currently-satisfactory product quickly, you don't know whether an architecture is good or not until you see how it copes with new requirements 3, 5, 10 years from inception.
People changing jobs/teams faster than that may simply never experience a feedback cycle on the real, long-term quality of their work.
Nearly all the software you actually use. Do you think things like Vault, Consul, Kubernetes, Apache, Nginx, NodeJS, NPM, React, VueJS, etc. etc. etc. were all "mature" one year in? Many of those are actually extremely simple and limited in functionality compared to actual "real" enterprise apps. What an amazingly naïve comment.
I’m not sure what methodology has to do with my point. Launching a system isn’t a big deal, evolving a system is harder to do, finally evolving an enterprise (system of systems) is measured in years. You don’t make architectural decisions over night and aligning multiple independent systems and services is a lot harder than your ignorant comment is aware of.
Yes, but the idea is that software changes as customer needs change. If not, then that is an out of date product, and by the time it would have become "mature" it would be out of fashion anyway. Good software is software that changes often, yet it maintains quality. Unlike in waterfall where it probably takes 2 years to release it, and by then it is already old. For "enterprise" software such as oracle or ibm products, that would not be a surprise, but for highly adaptable products, 2 months is the maximum something would not change.
In this case the article is talking about pretty expansive hardware projects, think GPS or a drone fleet and that software needs to be involved earlier with requirements and design instead of an afterthought.
That is quite different than the CRUD web application that most people are working with.
Even in "non expensive" (relative) HW projects. I've been doing mobile/embedded for a long time. Many experts, SW architects, HW architects are frequently consulted early & frequently throughout the process as no one can possibly have a complete picture. It's just impossible to do it any other way and ship things on time & meeting the quality bar.
Good point. I am coming from the web app point of view. I assumed the comment section was a bit more generic. Also i should have clarified what context i am referring to.
