And software engineers can't design cars that they don't drive. As evidenced by the millions of tons od e-waste rolling around on city streets these days.
You can't design software you don't work on
71–80 of 119 posts
Re: You can't design software you don't work on
#72In the best scenario the developers are also active users of the software they produce. Then a design flaw or an error that affects the users will also affect the developers and will (hopefully) motivate the latter to correct it.
XP putting a customer on the team was the best thing in the methodology. Replacing those with business representatives is one of Scrum's original sins.
> XP putting a customer on the team was the best thing in the methodology.
Recently my boss said to me: "Customers want something that WORKS. If you deliver something, and it doesn't work, what's the customer going to think?" The huge drawback to putting a customer on the team is that the customer probably doesn't want to know, let alone be involved with, how the sausage is made. They want a turnkey solution unveiled to them on the delivery date, all ready to go, with no effort on their part.
Generally what you want is a customer proxy in that role, who knows or can articulate what the customer needs better than the customer themselves can. Steve Jobs was a fantastic example of someone who filled this role.
Re: You can't design software you don't work on
#73> For instance: In large codebases, consistency is more important than “good design” But this is exactly the type of generic software design advice the article warns us about! And it mostly results in all all the bad software practices we as users know and love remaining unchanged (consistently "bad" is better than being good at least in some areas!)
My reading of it also violates the Boy Scout Rule. That is to say: if improving some portion of the codebase would make it better, but inconsistent, you should avoid the improvement; which is something that I would disagree with. I think adherence to “consistency is more important than ‘good design’” naturally leads to boiling the ocean refactoring and/or rewrites, which are far riskier endeavors with lower success r…
The problem with small refactors over time is that your information about what constitutes a good/complete model of your system increases over time as you understand customers and encounter edge cases. Small refactors over time can cause architectural churn and bad abstractions. Additionally, if you ever want to do a programmatic rewrite of code, with a bunch of small refactors that becomes more difficult, with a single surface you can sometimes just use a macro to change everything all at once.
This is an example of a premature optimization. The reason it can still be good is that large refactors are an art that most people haven't suffered enough to master. There are patterns to make it tractable, but it's riskier and engineers often aren't personally invested in their codebases enough to bother over just fixing the few things that personally drive them nuts.
Re: You can't design software you don't work on
#74As a personal anecdote in agreement with the article, I've seen design consultants come in with no industry experience and ruin projects. Friends of the VP with no satellite experience saying we need to introduce random exceptions everywhere who don't understand threading or type systems outside of Java. It's frustrating to see potential bugs introduced at the design level with no regard for how the end product operates
Re: You can't design software you don't work on
#75This is also the type of thing that makes having separate software architects that aren't actually maintaining the software generally a nonsensical idea. There are too many decisions, technical details, and active changes to have someone come in and give direction from on high at intervals. Maybe at the beginning it could make sense sort of, but projects have to evolve and more often than not discover something impor…
I guess I'm lucky not to have worked at a place with a role for software architects who don't actually write code. I honestly don't know how that would work. However, I think I can appreciate the author's point. Any sufficiently complex piece of existing software is kind of like a chess game in progress. There is a place for general principles of chess strategy, but once the game is going, general strategy is much less relevant than specific insights into the current state of play, and a player would probably not appreciate advice from someone who has read a lot of chess books but hasn't looked at the current state of the board.
Re: You can't design software you don't work on
#76Didn't read the article yet, but came here to say that I couldn't agree more with that sentence in the sense that the industry should stop making people "software architects", specially those that do not code at all but want to make design decisions. Software architect should be a role and not a position.
Re: You can't design software you don't work on
#77I'm wary of absolute statements about programming.
Re: You can't design software you don't work on
#78I completely disagree with almost the entirety of the article. It’s all about prior experience building large things many times yourself, not using some framework or other external abstraction. When you have done this many times you absolutely can design a large application without touching the code. This is part planning and risk analysis experience and part architecture experience. You absolutely need a lot of expe…
I have watched this comment bounce up and down in votes all day from 0 earlier in the day up to a max of 4 up votes and now back to 0. I really think this controversy goes to the extreme Dunning-Kruger of software. There are so many developers that are just unqualified button pressers who cannot see what they don't know, but for people who have enough experience to write original software there is common knowledge that most lesser developers cannot accept.
Re: You can't design software you don't work on
#79Earlier quoted context omitted.
> The software engineers' body of knowledge can change 52 times in a year Nah, those changes are only in the surface, at the most shallow level. There's always new techniques, materials and tools in structural engineering as well. Foundations take a lifetime to change.
Respectfully, I disagree. You're correct on the facts, but any "new techniques, materials and tools" need to be communicated to the brick layers. That takes time and effort i.e. it all needs to be actively managed. The brick layers have to be able to work with those new techniques and materials. I don't want some of them using method #1 over here, and method #2 over there, unless I'm wholly conversant with the method…
> Respectfully, I disagree. You're correct on the facts, but
I'm fine with the disagreement if you say I'm correct. ¯\_(ツ)_/¯
> any "new techniques, materials and tools" need to be communicated to the brick layers
Same for software.
> That takes time and effort i.e. it all needs to be actively managed. The brick layers have to be able to work with those new techniques and materials.
Same for software.
> I don't want some of them using method #1 over here, and method #2 over there, unless I'm wholly conversant with the methods, and fully confident that it'll all mesh eventually. The system i.e. the whole shebang has to work coherently to serve its purpose.
Same for software.
Virtually every profession has a body of knowledge that's constantly getting updated. Only software engineers seem to have this faulty assumption that they must apply it all immediately. Acknowledging it's a false assumption leads to a better life.
Re: You can't design software you don't work on
#80Earlier quoted context omitted.
> The software engineers' body of knowledge can change 52 times in a year Nah, those changes are only in the surface, at the most shallow level. There's always new techniques, materials and tools in structural engineering as well. Foundations take a lifetime to change.
> Nah, those changes are only in the surface, at the most shallow level. Very strongly disagree. There are limitless methods of solving problems with software (due to very few physical constraints) and there are an enormous number of different measures of whether it's "good" or "bad". It's both the blessing and curse of software.
Once again, that's only true at the surface level.
If you dig deeper you'll realize that it's possible to categorize techniques, tools, libraries, algorithms, recipes, whatever.
And if you dig even deeper, you'll realize that there is foundational knowledge that lets you understand a lot of things that people complain about being too new.
The biggest curse of software is people saying "no" to education and knowledge.