21 ms·

Is Design Dead? (2004)

111 points by nickwritesit 3y ago

thecolorblew 3y ago
[flagged]
- atleastoptimal 3y ago
  The law states that it works in all cases but the justification only refers to the publisher's confidence that the answer is no, not that a headline can magically change reality. Whether "design is dead" is a lot more nuanced than a simple yes or no
  - RankingMember 3y ago
    I always saw that "law" as more a critique of the use of such clickbait-y headlines rather than something to be taken seriously.
- inglor 3y ago
  The answer he gives in the article isn’t no though.
  - deleted 3y ago
    [deleted]
  - deleted 3y ago
    [deleted]
toss1 3y ago
The problem with the Planned Design vs Extreme Evolutionary Design is that BOTH are appropriate for different circumstances. I've found a balance that works well, almost by accident or necessity of the situation. At the outset with a new product, even if the team thinks they know what they are doing and what they intend, they really do not. This is (had better be) a new product/service, and no one really knows how it will really interact with the customers/users, and how the components will interact. You are about to build a MVP, then core product. THIS is the time for an extreme programming type approach. Get things working ASAP, get feedback from real users and real running systems. Most importantly, the ONLY PLAN is to THROW AWAY THIS VERSION. Then, once you have basic experience with your users, know what they prioritize, and experience with your system's behavior, NOW is the time to plan and design a system that will be scalable and maintainable. Depending on the project, situation, and how the throw-away version went, this may be after v0.9 or after v2.1, or maybe just after base or breakeven revenue or a funding round. The cool thing is that in the early times when speed is most critical to survival, all worries about technical debt are eliminated — it'll just be thrown away soon, and the scalability and maintainability issues are punted until you really have enough information to answer them well. So, extreme to start, then plan and design later.
- mark_undoio 3y ago
  It takes some strong organisational discipline to really maintain that throw away mindset - I suppose that's where it helps to make an explicit goal to throw the initial version away. Another aspect is that (in my experience / opinion) if you're doing an MVP then it really needs to be as minimal as possible - big enough to give you evidence for your future plans but not comparable to what you eventually hope to build. Otherwise it's hard to adapt or to throw away. The biggest thing I've found to help in any design work is making sure the engineers really understand the problem they're solving, so they can judge independently if plans they're making are complimentary to it.
  - perrygeo 3y ago
    > making sure the engineers really understand the problem they're solving Yes, absolutely. And how would software engineers gain that understanding? Experience is the key here. Avoiding an initial implementation because you're afraid of "wasting work" is counterproductive - it cuts off the primary mechanism by which developers gain understanding! That's like saying athletes shouldn't practice because it wastes their energy for the big game. One small note on terminology that might help: Using "MVP" implies that what you're developing is a product. It's more accurate to call this "POC" or proof-of-concept since that's exactly what it does - with that data in place, the product and engineering plans can proceed faster and more effectively knowing they have a firm tether to reality.
- germinalphrase 3y ago
  I have never had the experience of developing a product from MVP to mass market. Is ‘Throw Away then Strategize/Plan’ utilized with any regularity? Would it follow that the initial team who scraps together the MVP would be different than the Strategize/Plan team that might be hired specifically because they have the experience/background for building large scale systems (assuming expanded funding comes from market validation via the MVP)?
  - perrygeo 3y ago
    > Is ‘Throw Away then Strategize/Plan’ utilized with any regularity Yes. But I'd frame it a different way. The initial implementation is the source of empirical data that you need to formulate a viable plan. You're not building something to "throw it away". You're building something so that all subsequent decisions can be made on a solid foundation. To be concrete, I've seen teams faced with a technical decision who a) argue about it in meetings for weeks, bringing only opinions and personal experiences to the table vs. b) set up a proof of concept for all options and run benchmarks which can be used to make informed decisions. (a) takes longer and produces an inferior product - I've never seen an exception.
bern4444 3y ago
Once you get to the point of something working, the business is going to move on ahead without giving your team any time to go back to refine and improve. Bug fixes will be given some time but telling management/business, we need 2 months to go and clean up everything we've built over the last 6 since we now have an idea of how to structure this capability is gonna be met with a laugh and a no. Inevitably something will break or a new feature will not be possible cause of existing limitations and everyone will get mad since no one told them something could break without an improvement even though you told them well beforehand that the ground was shaky. I think companies not prone to this are ones where their product is a technical one like cloud services where the business really is the engineering and engineering isn't a means to an end.
- Scarblac 3y ago
  In practice it isn't even that much more likely to break, or even add features to. The code is just much uglier and more complex than it could be, and probably slower. But it runs and keeps running. Most of the time those business types are correct on this. The only thing is that once the original team has moved on, then if the code is too complex, it can become almost impossible to change.
  - ilyt 3y ago
    > Most of the time those business types are correct on this. If you can call it making problems after they leave "being correct".
  - malfist 3y ago
    It's a hard balance to strike. On one hand, the code is ugly and difficult to understand, but it has that ugliness for a reason, it's solving edge cases that you don't remember and a rip and replace is always expensive and no guarantee it won't devolve just as quickly. How do you strike the balance of the dev team wanting to fix unbroken code for long term health, and investing in new features that grow the business. Personally, I am biased towards encapsulation as a means to handle a lot of these types of tech debt. Wrap the old stuff in an orchestration layer and build new features with the orchestration layer in the middle. It's a bit of sweeping the dirt under a rug, but it also gives you a real solid base for later coming back and cleaning up the ugliness if it's really needed by giving solid contracts between the consumers and the orchestration layer and the legacy system and the orchestration layer.
inglor 3y ago
Needs a (2004) in the title. This is quite the classic from the days UML was used unironically.
- gwern 3y ago
  Or "(2000)", actually, since it seems to all be a 2000 keynote which has been digitized. Probably a good time for a retrospective - 23 years ought to provide a lot of hindsight & commentary.
  - deleted 3y ago
    [deleted]
- horeszko 3y ago
  I'm newer to software development and haven't used UML but have heard jokes about it. What was the deal with UML that it got its reputation?
  - mjr00 3y ago
    UML was, at least partly, advertised as something that would make software developers obsolete. You just needed domain experts to wire up the right class diagrams, sequence diagrams, activity diagrams, etc., and it would output code that met the specifications. No developers needed!
  - jprete 3y ago
    I think it has too much regimentation to be a good communication device, or even a good design specification. Labeled boxes, arrows, and sometimes color are more than sufficient for diagramming how a design works. The small details in a design doc are not going to stay the same when building the thing, so writing them down is just a waste of time. (Personally, I’m a fan of doing less design, less documentation, and making the code as obvious as possible. It’s a lot of friction to have multiple sources of truth that have to be kept in correspondence with each other.)
  - dgb23 3y ago
    Imagine you want to have a conversation with a colleague about how to approach a new project, but some smart-ass is constantly pestering you, forcing you to use a heavily formalized, technical language that requires you to put every idea into a well defined box. Caveats, questions and loosely defined entities, processes or relationships cannot be expressed.
manojlds 3y ago
Where's the 2004 in the title?
- legrande 3y ago
  It's a timeless piece. It doesn't need the 2004 context. It's all relevant today.
  - dang 3y ago
    Putting the year on older articles is just the convention on HN. https://hn.algolia.com/?dateRange=all&page=0&prefix=true&query=by%3Adang%20convention%20year%20title&sort=byDate&type=comment https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
ARandomerDude 3y ago
> Does Refactoring Violate YAGNI? I'm so glad the industry has largely moved passed this sort of dogmatic 'purism.' Conversations like this still happen of course, but they don't seem to happen with the frequency or volume that they did 20 years ago when this article was written.
- marginalia_nu 3y ago
  I think it's more of an evolutionary stage in a developer's career. Relatively inexperienced developers tend to very myopically zoom in on particular qualities that are supposedly good, and explain everything that is wrong with software and software development with the lack of this quality; and everything that is right with the presence of this quality. Of course this phase can't last too many years, as such conceptualizations don't tend to survive contact with the realities of software development. They'll inevitably encounter undeniably good code written with complete irreverence for their most holiest of ideals, and they'll themselves write bad code despite kneeling at the holy altar of clean code or memory safety or pure functions or whatever. Purism is ultimately a completely untenable position.
- feoren 3y ago
  YAGNI should be applied to things that you're adding. Features, database columns, interface methods, etc. Everything being added must have a need, and that need needs to be immediate and real. Refactoring is inherently not about adding anything. If you're adding things as part of refactoring, presumably it's in the service of removing even more things, such as in consolidating multiple similar abstractions into one. If you find yourself adding lots of new abstractions as part of refactoring, YAGNI applies. But "YAGNI applies" doesn't mean "don't do it", it means "make sure you actually do need it, right now, and not in some hypothetical future." There's a way to plan ahead for likely futures without adding features, and in my mind that doesn't violate YAGNI. You're not planning for one specific hypothetical future, you're trying to make sure your application is robust in the face of likely changes. You don't actually perform those changes, but you do ask yourself how those changes would work in your current application. I use the analogy of creating a model bridge for a train set. YAGNI would be looking at the bridge and saying "yeah but what about tanks? What if you wanted to land an airplane on that bridge?" -- until you're literally doing it, just stop. It's for model trains; the end. But going over to the bridge and jiggling it, shaking it, seeing if it makes a weird rattle, making sure it's level, pushing on it to see how it bends, and fixing it if any of those things happen -- that's not really YAGNI. That's making sure it's robust and will last into the future, however you decide to use it.
ChrisArchitect 3y ago
(2004)!
- ChrisArchitect 3y ago
  or even (2000)
- thought_alarm 3y ago
  Everybody's dropping C++ and learning Ruby.
ngc248 3y ago
With agile. there is no time for design
- yazzku 3y ago
  I create my Jiras with a deadline of yesterday.
  - gunapologist99 3y ago
    I can't tell if this is sarcasm or real, but either way it's the most brilliant thing I've read all day.
    - yazzku 3y ago
      That's what Jira does to you, can't tell if it's sarcasm anymore.
varjag 3y ago
Not sure about design but XP is dead for sure.
- deleted 3y ago
  [deleted]
eduction 3y ago
Unpopular opinion: There is not nearly enough design in most software development these days. Any sort of reasonable planning and writing and spec-ing tends to be derided as "waterfall"/Big Design Up Front and therefore inherently bad. You can blame Agile/XP but at root I think it has more to do with many developers abhorring tasks other than just writing code. Documents? Meetings? Talking to future end users? Not fun!! Then they get frustrated they don't get time to fix their tech debt. How about not going so into debt in the first place? By all means do some prototyping but then throw it away after a week or two. Use it to test hypotheses you've already written down somewhere. You'll have more success if you're asking for two weeks to clean up tech debt instead of two months.
- nine_zeros 3y ago
  > You can blame Agile/XP but at root I think it has more to do with many developers abhorring tasks other than just writing code. Documents? Meetings? Talking to future end users? Not fun!! In whatever BS performance review process in your company, are engineers going to be recognized for writing documents, meetings, talking to future and end users? If yes, engineers will do it. As it stands, in large companies, management just wants engineers to code their life out.
  - wldcordeiro 3y ago
    In my experience even when you want to do those things more often than not it's management that sees it as a waste of time and wants you to get to coding. So many times we've had to "pivot" in projects because management couldn't be bothered to let us plan any architecture.
    - ChikkaChiChi 3y ago
      I think this is the failure of the project leaders to incorporate usability into the discussion from the outset. It takes a strong will to sit there and say "We can build you what you want, but without at least one pass on usability and optimization, it's going to be fat, slow, and the end users are going to hate it."
gilessbrown 3y ago
Evolving a single software component is doable if the motivation is strong enough. Evolving a software system not so much. You're gonna live with the principles you baked in 99 times out of 100.
deleted 3y ago
[deleted]
deleted 3y ago
[deleted]
lxe 3y ago
UML != design. People simply don't want to be translating across various definition languages and just write code instead. The codebase itself, if organized well, can serve as a design definition just as well as UML does.
jt2190 3y ago
> … [Extreme Programming (XP), an early “agile” method] involves a lot of design, but does it in a different way than established software processes. XP has rejuvenated the notion of evolutionary design with practices that allow evolution to become a viable design strategy. It also provides new challenges and skills as designers need to learn how to do a simple design, how to use refactoring to keep a design clean, and how to use patterns in an evolutionary style. (Emphasis mine) So, have we met the challenge of: * implementing a simple design first, then * iterating (“refactoring”), the original design as more information is uncovered, then * ensuring that the design is implemented using well-worn solutions (“patterns”) ? I think that there are social forces that work against this ideal, specifically: * Software projects are funded as if they’ll be “done” on a certain date, after which improving the implementation will be considered too risky/not worth it. * Developers like to code, and designing (reading other people’s code, negotiating improvements etc.) is not what they want to do. Best to jump to a greenfield project that isn’t boring “maintenance” work. This results in a lot of half-designed, half-done, “works well enough just don’t touch it” software.
Joel_Mckay 3y ago
Most modern software is E-type systems, and by that very nature [d]evolve into API specifications even if your team intended something completely different. Reasonable frameworks tend to accelerate this common trend by starting off with a well defined visitor and or facade pattern. The current key design principle is to colocate problem domains in confined modular partitions with those responsible. If the team leads don't do this, than the infrastructure rots with fragile products in less than 18 months. Sisyphus design principles are rarely excusable. Best of luck, =)
thrashh 3y ago
To me, whether you use waterfall or agile or something in between, or whether your managers give you full independence or measure every little metric, or whether you choose to do a lot of design up front or build a MVP right away, ultimately has little impact on the future of your codebase. Nothing replaces experience in the domain. For an example, if your domain requires N-addresses per customer and you build the system allowing only 1 address across all your systems, you will probably be stuck in a refactor/rewrite hell-hole down the line. I don't think any amount of planning or lack of planning or waterfall or agile could guarantee you figuring this out, but someone that has worked in the field for 10 years could tell you in 5 seconds.
- appplication 3y ago
  Definitely agree, and I think the place that I’ve seen most errors manifest is often the data model (including your example). APIs can always have a v2, classes can be extended, front ends can be reworked… but the data model is essentially the last line where abstractions end. It will forever codify the burden of representing hopeful future states while needing to account for every past state. Database migrations can be costly, risky, and often difficult to revert. I might also see the world this way right now because I’m currently deep in data model/migration hell with my current project due to my formerly (and possibly still presently) incomplete understanding of how the system and use cases would evolve over time.
jschveibinz 3y ago
There is an important topic missing from the article and conversation: cost and schedule. Efficiency is the real impetus for good engineering design. The author mentions “other engineering disciplines” use design to ensure proper functionality. But design engineering is about spending the least amount of money and time to meet the specified requirements, including production. For example, bridges are designed and built using just the right amount of strength and durability (with a safety factor) with the least amount of effort, and not much more. Software should be designed to meet the bare minimum requirements to be built in the most cost and schedule efficient fashion, and not much more. Standards, languages, API’s, IDE’s, operating systems, databases, etc. should all be chosen to meet the minimum requirements with: 1. the minimum amount of time; 2. the minimum amount of cost; and 3. the maximum amount of flexibility and/or support-ability for future adaptations. …and not much more. This is the goal of good software engineering design.
jcarrano 3y ago
Most software out there follows the "Big Ball of Mud" [1] essay almost verbatim. My (anecdotal) rule of thumb is that after around 10 years of this kind of development, the inefficiency grows so big that development stalls. That happens when the ratio of new features to new breakages approaches one. Then the company adds more and more developers to work on the same codebase, which will not help because their productivity will be super-slow. Instead they should be working in rebuilding the product. Of course, at some point doing a huge design and making everything technically perfect from the beginning is wasteful. The main mistake to me, however, is not realizing the long-term costs and that doing it "right" is not so expensive. One does not even need to design everything, just have enough foresight to not paint oneself into a corner design-wise. [1] http://www.laputan.org/mud/mud.html http://www.laputan.org/mud/mud.html

111 points by nickwritesit 3y ago

thecolorblew 3y ago

[flagged]

atleastoptimal 3y ago
The law states that it works in all cases but the justification only refers to the publisher's confidence that the answer is no, not that a headline can magically change reality. Whether "design is dead" is a lot more nuanced than a simple yes or no
- RankingMember 3y ago
  I always saw that "law" as more a critique of the use of such clickbait-y headlines rather than something to be taken seriously.
inglor 3y ago
The answer he gives in the article isn’t no though.
- deleted 3y ago
  [deleted]
- deleted 3y ago
  [deleted]

toss1 3y ago

The problem with the Planned Design vs Extreme Evolutionary Design is that BOTH are appropriate for different circumstances. I've found a balance that works well, almost by accident or necessity of the situation. At the outset with a new product, even if the team thinks they know what they are doing and what they intend, they really do not. This is (had better be) a new product/service, and no one really knows how it will really interact with the customers/users, and how the components will interact. You are about to build a MVP, then core product. THIS is the time for an extreme programming type approach. Get things working ASAP, get feedback from real users and real running systems. Most importantly, the ONLY PLAN is to THROW AWAY THIS VERSION. Then, once you have basic experience with your users, know what they prioritize, and experience with your system's behavior, NOW is the time to plan and design a system that will be scalable and maintainable. Depending on the project, situation, and how the throw-away version went, this may be after v0.9 or after v2.1, or maybe just after base or breakeven revenue or a funding round. The cool thing is that in the early times when speed is most critical to survival, all worries about technical debt are eliminated — it'll just be thrown away soon, and the scalability and maintainability issues are punted until you really have enough information to answer them well. So, extreme to start, then plan and design later.

mark_undoio 3y ago
It takes some strong organisational discipline to really maintain that throw away mindset - I suppose that's where it helps to make an explicit goal to throw the initial version away. Another aspect is that (in my experience / opinion) if you're doing an MVP then it really needs to be as minimal as possible - big enough to give you evidence for your future plans but not comparable to what you eventually hope to build. Otherwise it's hard to adapt or to throw away. The biggest thing I've found to help in any design work is making sure the engineers really understand the problem they're solving, so they can judge independently if plans they're making are complimentary to it.
- perrygeo 3y ago
  > making sure the engineers really understand the problem they're solving Yes, absolutely. And how would software engineers gain that understanding? Experience is the key here. Avoiding an initial implementation because you're afraid of "wasting work" is counterproductive - it cuts off the primary mechanism by which developers gain understanding! That's like saying athletes shouldn't practice because it wastes their energy for the big game. One small note on terminology that might help: Using "MVP" implies that what you're developing is a product. It's more accurate to call this "POC" or proof-of-concept since that's exactly what it does - with that data in place, the product and engineering plans can proceed faster and more effectively knowing they have a firm tether to reality.
germinalphrase 3y ago
I have never had the experience of developing a product from MVP to mass market. Is ‘Throw Away then Strategize/Plan’ utilized with any regularity? Would it follow that the initial team who scraps together the MVP would be different than the Strategize/Plan team that might be hired specifically because they have the experience/background for building large scale systems (assuming expanded funding comes from market validation via the MVP)?
- perrygeo 3y ago
  > Is ‘Throw Away then Strategize/Plan’ utilized with any regularity Yes. But I'd frame it a different way. The initial implementation is the source of empirical data that you need to formulate a viable plan. You're not building something to "throw it away". You're building something so that all subsequent decisions can be made on a solid foundation. To be concrete, I've seen teams faced with a technical decision who a) argue about it in meetings for weeks, bringing only opinions and personal experiences to the table vs. b) set up a proof of concept for all options and run benchmarks which can be used to make informed decisions. (a) takes longer and produces an inferior product - I've never seen an exception.

bern4444 3y ago

Once you get to the point of something working, the business is going to move on ahead without giving your team any time to go back to refine and improve. Bug fixes will be given some time but telling management/business, we need 2 months to go and clean up everything we've built over the last 6 since we now have an idea of how to structure this capability is gonna be met with a laugh and a no. Inevitably something will break or a new feature will not be possible cause of existing limitations and everyone will get mad since no one told them something could break without an improvement even though you told them well beforehand that the ground was shaky. I think companies not prone to this are ones where their product is a technical one like cloud services where the business really is the engineering and engineering isn't a means to an end.

Scarblac 3y ago
In practice it isn't even that much more likely to break, or even add features to. The code is just much uglier and more complex than it could be, and probably slower. But it runs and keeps running. Most of the time those business types are correct on this. The only thing is that once the original team has moved on, then if the code is too complex, it can become almost impossible to change.
- ilyt 3y ago
  > Most of the time those business types are correct on this. If you can call it making problems after they leave "being correct".
- malfist 3y ago
  It's a hard balance to strike. On one hand, the code is ugly and difficult to understand, but it has that ugliness for a reason, it's solving edge cases that you don't remember and a rip and replace is always expensive and no guarantee it won't devolve just as quickly. How do you strike the balance of the dev team wanting to fix unbroken code for long term health, and investing in new features that grow the business. Personally, I am biased towards encapsulation as a means to handle a lot of these types of tech debt. Wrap the old stuff in an orchestration layer and build new features with the orchestration layer in the middle. It's a bit of sweeping the dirt under a rug, but it also gives you a real solid base for later coming back and cleaning up the ugliness if it's really needed by giving solid contracts between the consumers and the orchestration layer and the legacy system and the orchestration layer.

inglor 3y ago

Needs a (2004) in the title. This is quite the classic from the days UML was used unironically.

gwern 3y ago
Or "(2000)", actually, since it seems to all be a 2000 keynote which has been digitized. Probably a good time for a retrospective - 23 years ought to provide a lot of hindsight & commentary.
- deleted 3y ago
  [deleted]
horeszko 3y ago
I'm newer to software development and haven't used UML but have heard jokes about it. What was the deal with UML that it got its reputation?
- mjr00 3y ago
  UML was, at least partly, advertised as something that would make software developers obsolete. You just needed domain experts to wire up the right class diagrams, sequence diagrams, activity diagrams, etc., and it would output code that met the specifications. No developers needed!
- jprete 3y ago
  I think it has too much regimentation to be a good communication device, or even a good design specification. Labeled boxes, arrows, and sometimes color are more than sufficient for diagramming how a design works. The small details in a design doc are not going to stay the same when building the thing, so writing them down is just a waste of time. (Personally, I’m a fan of doing less design, less documentation, and making the code as obvious as possible. It’s a lot of friction to have multiple sources of truth that have to be kept in correspondence with each other.)
- dgb23 3y ago
  Imagine you want to have a conversation with a colleague about how to approach a new project, but some smart-ass is constantly pestering you, forcing you to use a heavily formalized, technical language that requires you to put every idea into a well defined box. Caveats, questions and loosely defined entities, processes or relationships cannot be expressed.

manojlds 3y ago

Where's the 2004 in the title?

legrande 3y ago
It's a timeless piece. It doesn't need the 2004 context. It's all relevant today.
- dang 3y ago
  Putting the year on older articles is just the convention on HN. https://hn.algolia.com/?dateRange=all&page=0&prefix=true&query=by%3Adang%20convention%20year%20title&sort=byDate&type=comment https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...

ARandomerDude 3y ago

> Does Refactoring Violate YAGNI? I'm so glad the industry has largely moved passed this sort of dogmatic 'purism.' Conversations like this still happen of course, but they don't seem to happen with the frequency or volume that they did 20 years ago when this article was written.

marginalia_nu 3y ago
I think it's more of an evolutionary stage in a developer's career. Relatively inexperienced developers tend to very myopically zoom in on particular qualities that are supposedly good, and explain everything that is wrong with software and software development with the lack of this quality; and everything that is right with the presence of this quality. Of course this phase can't last too many years, as such conceptualizations don't tend to survive contact with the realities of software development. They'll inevitably encounter undeniably good code written with complete irreverence for their most holiest of ideals, and they'll themselves write bad code despite kneeling at the holy altar of clean code or memory safety or pure functions or whatever. Purism is ultimately a completely untenable position.
feoren 3y ago
YAGNI should be applied to things that you're adding. Features, database columns, interface methods, etc. Everything being added must have a need, and that need needs to be immediate and real. Refactoring is inherently not about adding anything. If you're adding things as part of refactoring, presumably it's in the service of removing even more things, such as in consolidating multiple similar abstractions into one. If you find yourself adding lots of new abstractions as part of refactoring, YAGNI applies. But "YAGNI applies" doesn't mean "don't do it", it means "make sure you actually do need it, right now, and not in some hypothetical future." There's a way to plan ahead for likely futures without adding features, and in my mind that doesn't violate YAGNI. You're not planning for one specific hypothetical future, you're trying to make sure your application is robust in the face of likely changes. You don't actually perform those changes, but you do ask yourself how those changes would work in your current application. I use the analogy of creating a model bridge for a train set. YAGNI would be looking at the bridge and saying "yeah but what about tanks? What if you wanted to land an airplane on that bridge?" -- until you're literally doing it, just stop. It's for model trains; the end. But going over to the bridge and jiggling it, shaking it, seeing if it makes a weird rattle, making sure it's level, pushing on it to see how it bends, and fixing it if any of those things happen -- that's not really YAGNI. That's making sure it's robust and will last into the future, however you decide to use it.

ChrisArchitect 3y ago

(2004)!

ChrisArchitect 3y ago
or even (2000)
thought_alarm 3y ago
Everybody's dropping C++ and learning Ruby.

ngc248 3y ago

With agile. there is no time for design

yazzku 3y ago
I create my Jiras with a deadline of yesterday.
- gunapologist99 3y ago
  I can't tell if this is sarcasm or real, but either way it's the most brilliant thing I've read all day.
  - yazzku 3y ago
    That's what Jira does to you, can't tell if it's sarcasm anymore.

varjag 3y ago

Not sure about design but XP is dead for sure.

deleted 3y ago
[deleted]

eduction 3y ago

Unpopular opinion: There is not nearly enough design in most software development these days. Any sort of reasonable planning and writing and spec-ing tends to be derided as "waterfall"/Big Design Up Front and therefore inherently bad. You can blame Agile/XP but at root I think it has more to do with many developers abhorring tasks other than just writing code. Documents? Meetings? Talking to future end users? Not fun!! Then they get frustrated they don't get time to fix their tech debt. How about not going so into debt in the first place? By all means do some prototyping but then throw it away after a week or two. Use it to test hypotheses you've already written down somewhere. You'll have more success if you're asking for two weeks to clean up tech debt instead of two months.

nine_zeros 3y ago
> You can blame Agile/XP but at root I think it has more to do with many developers abhorring tasks other than just writing code. Documents? Meetings? Talking to future end users? Not fun!! In whatever BS performance review process in your company, are engineers going to be recognized for writing documents, meetings, talking to future and end users? If yes, engineers will do it. As it stands, in large companies, management just wants engineers to code their life out.
- wldcordeiro 3y ago
  In my experience even when you want to do those things more often than not it's management that sees it as a waste of time and wants you to get to coding. So many times we've had to "pivot" in projects because management couldn't be bothered to let us plan any architecture.
  - ChikkaChiChi 3y ago
    I think this is the failure of the project leaders to incorporate usability into the discussion from the outset. It takes a strong will to sit there and say "We can build you what you want, but without at least one pass on usability and optimization, it's going to be fat, slow, and the end users are going to hate it."

gilessbrown 3y ago

Evolving a single software component is doable if the motivation is strong enough. Evolving a software system not so much. You're gonna live with the principles you baked in 99 times out of 100.

deleted 3y ago

[deleted]

deleted 3y ago

[deleted]

lxe 3y ago

UML != design. People simply don't want to be translating across various definition languages and just write code instead. The codebase itself, if organized well, can serve as a design definition just as well as UML does.

jt2190 3y ago

> … [Extreme Programming (XP), an early “agile” method] involves a lot of design, but does it in a different way than established software processes. XP has rejuvenated the notion of evolutionary design with practices that allow evolution to become a viable design strategy. It also provides new challenges and skills as designers need to learn how to do a simple design, how to use refactoring to keep a design clean, and how to use patterns in an evolutionary style. (Emphasis mine) So, have we met the challenge of: * implementing a simple design first, then * iterating (“refactoring”), the original design as more information is uncovered, then * ensuring that the design is implemented using well-worn solutions (“patterns”) ? I think that there are social forces that work against this ideal, specifically: * Software projects are funded as if they’ll be “done” on a certain date, after which improving the implementation will be considered too risky/not worth it. * Developers like to code, and designing (reading other people’s code, negotiating improvements etc.) is not what they want to do. Best to jump to a greenfield project that isn’t boring “maintenance” work. This results in a lot of half-designed, half-done, “works well enough just don’t touch it” software.

Joel_Mckay 3y ago

Most modern software is E-type systems, and by that very nature [d]evolve into API specifications even if your team intended something completely different. Reasonable frameworks tend to accelerate this common trend by starting off with a well defined visitor and or facade pattern. The current key design principle is to colocate problem domains in confined modular partitions with those responsible. If the team leads don't do this, than the infrastructure rots with fragile products in less than 18 months. Sisyphus design principles are rarely excusable. Best of luck, =)

thrashh 3y ago

To me, whether you use waterfall or agile or something in between, or whether your managers give you full independence or measure every little metric, or whether you choose to do a lot of design up front or build a MVP right away, ultimately has little impact on the future of your codebase. Nothing replaces experience in the domain. For an example, if your domain requires N-addresses per customer and you build the system allowing only 1 address across all your systems, you will probably be stuck in a refactor/rewrite hell-hole down the line. I don't think any amount of planning or lack of planning or waterfall or agile could guarantee you figuring this out, but someone that has worked in the field for 10 years could tell you in 5 seconds.

appplication 3y ago
Definitely agree, and I think the place that I’ve seen most errors manifest is often the data model (including your example). APIs can always have a v2, classes can be extended, front ends can be reworked… but the data model is essentially the last line where abstractions end. It will forever codify the burden of representing hopeful future states while needing to account for every past state. Database migrations can be costly, risky, and often difficult to revert. I might also see the world this way right now because I’m currently deep in data model/migration hell with my current project due to my formerly (and possibly still presently) incomplete understanding of how the system and use cases would evolve over time.

jschveibinz 3y ago

There is an important topic missing from the article and conversation: cost and schedule. Efficiency is the real impetus for good engineering design. The author mentions “other engineering disciplines” use design to ensure proper functionality. But design engineering is about spending the least amount of money and time to meet the specified requirements, including production. For example, bridges are designed and built using just the right amount of strength and durability (with a safety factor) with the least amount of effort, and not much more. Software should be designed to meet the bare minimum requirements to be built in the most cost and schedule efficient fashion, and not much more. Standards, languages, API’s, IDE’s, operating systems, databases, etc. should all be chosen to meet the minimum requirements with: 1. the minimum amount of time; 2. the minimum amount of cost; and 3. the maximum amount of flexibility and/or support-ability for future adaptations. …and not much more. This is the goal of good software engineering design.

jcarrano 3y ago

Most software out there follows the "Big Ball of Mud" [1] essay almost verbatim. My (anecdotal) rule of thumb is that after around 10 years of this kind of development, the inefficiency grows so big that development stalls. That happens when the ratio of new features to new breakages approaches one. Then the company adds more and more developers to work on the same codebase, which will not help because their productivity will be super-slow. Instead they should be working in rebuilding the product. Of course, at some point doing a huge design and making everything technically perfect from the beginning is wasteful. The main mistake to me, however, is not realizing the long-term costs and that doing it "right" is not so expensive. One does not even need to design everything, just have enough foresight to not paint oneself into a corner design-wise. [1] http://www.laputan.org/mud/mud.html http://www.laputan.org/mud/mud.html