In 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.
You can't design software you don't work on
11–20 of 119 posts
Re: You can't design software you don't work on
#12The second footnote acknowledges that the post is largely tautological.
Re: You can't design software you don't work on
#13Very impressed at the rate of high-quality interesting posts from this author.
Re: You can't design software you don't work on
#14I 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…
You’re speaking of implementing yet another system of a familiar kind, I.e. a new project. The OP says that generic design works for new projects. He’s mostly talking about designing new features to be added to an existing system, in which case the design has to be contingent on the existing system.
Re: You can't design software you don't work on
#15> 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!)
I don’t know. At my place a lot of cowboy engineers decided to do things their own way. So now we have the random 10k lines written in Redux (not used anywhere else) that no one likes working with. Then there’s the part that randomly uses some other query library because they didn’t like the one we use in 95% of the code for some reason, so if you ever want to work with that code you need to keep two libraries in your head instead of one. Yes, the existing query library is out of date. Yes, the new one is better— in isolation. But having both is even worse than having the bad one!
Re: You can't design software you don't work on
#16> 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!)
Moreover, saying that consistency is more important than good design is like saying that eating leafy greens is more important than a good diet.
Re: You can't design software you don't work on
#17> 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!)
I feel like “be consistent” is a rule that applies very broadly.
There’s absolutely exceptions and nuances. But I think when weighing trade-offs, program makers by and large deeply under-weigh being consistent.
Re: You can't design software you don't work on
#18> 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!)
I don’t know. At my place a lot of cowboy engineers decided to do things their own way. So now we have the random 10k lines written in Redux (not used anywhere else) that no one likes working with. Then there’s the part that randomly uses some other query library because they didn’t like the one we use in 95% of the code for some reason, so if you ever want to work with that code you need to keep two libraries in you…
It's essentially the same problem as https://xkcd.com/927/ [How Standards Proliferate]
Re: You can't design software you don't work on
#19> 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!)
Yeah its called the expectations, consistently bad is predictable
software that has "good" and "bad" parts in unpredictable
Re: You can't design software you don't work on
#20> 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!)
Yeah its called the expectations, consistently bad is predictable software that has "good" and "bad" parts in unpredictable
So we should all write bad code to keep it predictable? raising the quality of the codebase is unacceptable under this premise.