How To Avoid Designing A Big Ball Of Mud (YAGNI)

What is good design and how can we tell the difference between that and bad software design? Extreme Programming introduced some key ideas about software design, that often get overlooked. YAGNI, “You Ain’t Gonna Need It”, and an evolutionary design approach that Kent Beck referred to as "design through refactoring”. YAGNI was aimed at avoiding the over-engineering tendency inherent in designing too far ahead with big-up-front-design. So how do you tread the line between keeping the door open to change, as our understanding of the system grows, vs over-engineering and big ball of mud legacy systems?
In this episode Dave Farley, author of “Continuous Delivery” and “Modern Software Engineering”, explores how to manage complexity in software systems, and how to adopt an evolutionary approach to design that ensures that we can change our software as we learn more.
-------------------------------------------------------------------------------------
Also from Dave:
🎓 CD TRAINING COURSES
If you want to learn Continuous Delivery and DevOps skills, check out Dave Farley's courses
➡️ bit.ly/DFTraining
📧 Get a FREE guide "How to Organise Software Teams" by Dave Farley when you join our CD MAIL LIST 📧
The best way to keep in touch with the latest discussions, events and new training courses, get FREE guides and exclusive offers. ➡️ www.subscribepage.com/organis...
_____________________________________________________
🔗 LINKS:
📖 YAGNI, Wikipedia: en.wikipedia.org/wiki/You_are...
_____________________________________________________
📚 BOOKS:
📖 "Continuous Delivery Pipelines" by Dave Farley
paperback ➡️ amzn.to/3gIULlA
ebook version ➡️ leanpub.com/cd-pipelines
📖 Dave’s NEW BOOK "Modern Software Engineering" is available here
➡️ amzn.to/3DwdwT3
📖 The original, award-winning "Continuous Delivery" book by Dave Farley and Jez Humble ➡️ amzn.to/2WxRYmx
📖 Extreme Programming Explained: Embrace Change, Kent Beck: ➡️ amzn.to/2GpQRjE
NOTE: If you click on one of the Amazon Affiliate links and buy the book, Continuous Delivery Ltd. will get a small fee for the recommendation with NO increase in cost to you.
-------------------------------------------------------------------------------------
CHANNEL SPONSORS:
Equal Experts is a product software development consultancy with a network of over 1,000 experienced technology consultants globally. They increase the pace of innovation by using modern software engineering practices that embrace Continuous Delivery, Security, and Operability from the outset ➡️ bit.ly/3ASy8n0
Octopus are the makers of Octopus Deploy the single place for your team to manage releases, automate deployments, and automate the runbooks that keep your software operating. ➡️ oc.to/Dave-Farley
SpecFlow Behavior Driven Development for .NET SpecFlow helps teams bind automation to feature files and share the resulting examples as Living Documentation across the team and stakeholders. ➡️ go.specflow.org/dave_farley
TransFICC provides low-latency connectivity, automated trading workflows and e-trading systems for Fixed Income and Derivatives. TransFICC resolves the issue of market fragmentation by providing banks and asset managers with a unified low-latency, robust and scalable API, which provides connectivity to multiple trading venues while supporting numerous complex workflows across asset classes such as Rates and Credit Bonds, Repos, Mortgage-Backed Securities and Interest Rate Swaps ➡️ transficc.com

[@sdwone]

After 10+ years coding professionally, and about another 30 dabbling code as a serious hobby since I was 8, I'm totally down with this idea of 'Good Incremental Design'. Coding is ultimately a HUGELY complex process! For all but the most trivial of programs, building your code up carefully, brick by brick, testing EACH brick as you go along, changing your mind frequently, and refactoring as much as possible before moving onto the NEXT brick, is the ONLY sure fire way of creating the best code possible. As human beings, being able to break down complex problems into easily digestible smaller ones, and then testing, experimenting and changing each sub-solution you come up with for each sub-problem, is a tried and tested methodology which has served our civilization well for generations! Not just in coding but in countless other endeavours too! However, in the Real World, when dealing with a plethora of other devs who have differing, perhaps even polar opposite philosophies, as well as users that don't really know what they want, or why they want it, coupled with pushy, over ambitious managers, who don't have a clue about the daily challenged developers face... Then yeah... This idea does sound quite fanciful and way too idealistic! Nonetheless, the core principles are sound: Break up complex problems into easier smaller ones... And then build from there in such a way that CHANGE is embraced by the overall system. Because CHANGE will happen, no matter how good or bad your design is! CHANGE will happen, because the vast majority of software we write is for other human beings who, like us, CHANGE their minds more often than not!

[@robmorgan1214]

Great analysis. Great points!

[@rylaczero3740]

Thank you for distilling your 30 years of programming experience. Much appreciated.

[@alexsarbu3978]

After reading some comments, I have to highly recommend Dave's book - "Modern Software Engineering". His ideas are the opposite of a "no design", cowboy-style programming; it's about engineering, folks! And engineering isn't random.

[@ContinuousDelivery]

Thanks 😎

[@brownhorsesoftware3605]

Thanks for another super video. I'm beginning to think that the most important thing to learn as a programmer is how your brain works. My brain does not go to solutions when someone describes a problem, instead it goes into a kind of absorb mode that generates questions. Later, when I pick up a pen, it goes into thinking on paper (graph preferred) to describe, organize, and begin having ideas about the problem. That generates a list of things to explore and research. It is only as this stage progresses that I begin to formulate possible solutions. I always do the easiest things first. Start with something that runs and build from there so you implement what is needed as you need it. Make notes on what is needed as you go. Things you learn on the easy stuff will probably make the hard stuff simpler. Through the entire process I think on paper so I can check things off and remember where I am. I don't think in code, I think on paper - probably due to decades of working in assembler. I do, however, dream in code and rely on sleep to find complicated bugs. When I type code my brain goes into an edit/organize mode quite distinct from the writing with a pen creative mode. Some academic study discovered better exam outcomes for students when taking hand-written notes vs typing on a laptop.

[@ContinuousDelivery]

I remember when working hard on something, dreaming in assembler and wondering about my sanity 🤣🤣

[@adriannuske]

I'm a regular viewer. It's fairly sustained already, to say that this is amongst the best software related channels there are. I can proudly say that after twenty some years in the business, I've been through most, if not all, the dead-ends and bloat-making piles of crap here described. I come here to sometimes learn something new, and sometimes I get validation and petting, and I purr in pride. Thanks Dave. Truely!

[@ContinuousDelivery]

Thank you, I am pleased that you like my stuff.

[@bernhardkrickl5197]

Same :)

[@timseguine2]

This comes up for me a lot because of my long standing mindset of "get shit done". I end up implementing lots of great code that I probably don't need, because I switched from design mode into focus mode before it was time and it is sometimes hard to get out of focus mode. Oh well. I commit anyway, then delete the bits I don't need. I can pull out the good bits later from version control if it turns out I actually did need them.

[@miroslavisikiyski4876]

Can't get enough of your content, Dave. Amazing work

[@edgeeffect]

This is really helpful. One of the biggest problems I've had with management is that some massively favour under engineering and others massively favour over engineering... I've always sought to push them towards the middle way and any help articulating that is dead helpful.

[@shashank.c]

Kool, you had playing cards at your desk!! Your workplace is awesome!!! 👍🏻

[@epiderpski]

"My first design ideas are usually dumb"

[@RudhinMenon]

Thank you for all your efforts, most developers out there got no idea what they doing, including me. Earlier I used to believe that we should think through all possible pitfall beforehand and design accordingly. Later as and when a change occurs, try to accommodate the change in the least invasive way. It looks like it is mostly a balancing act, what do you think ?

[@AntonisDoomka]

Thanks! Very useful 👍

[@ShreksSpliff]

I keep forgetting to make small changes, thanks for saying it again x

[@BryonLape]

I still find it interesting how often Harlan Mill's step-wise refinement of design comes up over and over again, without attribution.

[@BobFrTube]

I describe my process as kneading code into shape. I remember back in 1969 when I realized rather than writing my code on paper, I could do it at the terminal and start with scaffolding expecting it to evolve and be reworked. This is a reason I like TypeScript since it allows me to be as strict as I want to be without having to be strict everywhere, especially when I'm learning by doing. I just did a complete rewrite of a 25-year old C# project by doing a complete rewrite in TS so I could make ii it understandable again.

[@ContinuousDelivery]

Yes, I don't think I have ever seen anyone work on anything that is more that a trivial few lines, do anything else. They don't always think of it that way, but seems to be always how it actually works.

[@fennecbesixdouze1794]

Example 1 and 2 that you gave around ~15:00 in I think of in terms of top-down design. You can either design bottom-up "hmm, what will I need to keep track of the books? I'll need a hash-map, so let's ..." etc etc. You are thinking through an initial implementation and then using your implementation to driving your refactor to interfaces. Top-down design would instead look like: "okay, what do I need, well I don't know where I'll get the books from yet, it could be a hash table or something but let's not commit to anything, let's just call that the Warehouse, let's stub out the interface and keep moving forward" etc etc. Top-down design is about building interfaces that model the problem, in language of the domain experts and in metaphors. Either top-down or bottom-up design can fall prey to over-engineering. Doing top-down design well doesn't mean big-design up front, note that when you're doing top-down design well, often times you are specifically stubbing out stuff you don't want to think about or over-engineer. You are thinking at a higher level precisely so you can express the problem in simple terms, by delaying implementation details as long as possible.

[@mwildam]

I totally agree with you, that software should be designed for change - for maintainability. And I totally agree with you, that even when trying hard to understand the problem, change of requirements are around the corner. But that is not just because of you maybe don't understanding the problem well. It could be simply some managers changing ideas or they need to react on market or environment changes. So even, if you get the problem right, the problem might change. But there is one thing that I see bad and really bad direction where we are going: Because of the minimalistic approach and the secure feeling that everything can be refactored later, we see a dependency hell worse than ever! - And there are even big frameworks totally ignoring the mass of people using it out there and do massive refactoring either of the public interfaces. There is a lot of work produced leading to developers having no time to update and so a large amount of technical dept is created. Waterfal model was rigid, but the good part was, that people spent more time on big pictures. Dreaming of possible future requirements tend to drive you into a more flexible design of solutions. But everybody goes for the quick way solving the problem at hand ignoring the next problem waiting already around the corner.

[@TheBoing2001]

So true. I feel that there is a trend to bash "legacy" software with that pseudo "technical debt" coming from people having never build any, and who would like to mimic past success mostly by hand waving. With luck you've taken/had the time to "debt" yourself by building your design "expansible" (*not* changeable). Refactoring million of line of code is a pipe dream (and | or hell). The extreme programming described here seems more like the thing everybody does when indulging in toying with code aimlessly (that's fun, all toys are, you do learn a lot this way). But that's *not* what designing a software is, especially not one maintainable enough to actually create real value (I mean money) so later new-evangelist can get paid to complain about "debt", and impose pseudo agile *fixed methodology* that is just waterfall in disguised (Dave quite nailed this one) But Dave is horribly wrong about YAGNI. That's precisely what make a good design in software. e.g. you've placed that gap in your binary RPC packet, because you *don't know* what extension will be needed in the future. You work with abstraction, but you make them richer than needed. It is pure hubris to pretend we know what would *and would not* be needed. Keep all door open, even the back one. Then there is the fallacy of the golden mean, because "random chaos" is clearly best for small program (go crazy do functional programming, weakly typed) , while "big upfront design" is paramount for big project with big lifetime (use OO, type strongly as hell, use every trick possible to have bearing structure, yes this even include test 😁

[@mwildam]

@@TheBoing2001 And another thing I find terribly crazy: There is inversion of dependency and dependency injection everywhere, but then hard wired in monoliths. I mean, interfaces were invented to plug in and extend software. It should be as simple, as dropping in a few libraries into a folder to get a plugin or extension running.

[@TheBoing2001]

@@mwildam Indeed, I use to call them Factories, and even those should contain "vague/expandable" context as parameter, so that the "injection" can be both decided by external configuration but also on client ever changing need (or runtime context). Or maybe we need a Factory for you Factories ? Something you aren't going to need... until you do !

[@kdietz65]

Good video. Made me think of this ... I really hate it when my IDE gives me an "unused method" warning. I'm designing a reasonable surface area of an interface, making completely reasonable extrapolations of the kinds of questions a future caller might want to ask of my object. The properties and methods I come up with have a sense of completeness to them. I don't care if no one is calling them RIGHT NOW. I have a reasonable expectation that callers in the near future will need this information. Then you know what'll happen in the PR? Someone will tell me to take the method out because it's not being used. NO!!!!!! That's just not the way I operate. It can be so frustrating.

[@materialknight]

Sometimes, an "unused method" warning is useful though. Among JavaScript's bullshit "features", is that you can declare many functions with the same name without triggering an error; JavaScript just assumes that you want to use the function you declared last, for all of your calls. So, if, by mistake, you declare a function with the same name as a previous one, you'll be scratching your head wondering why something unrelated with the current task has broken somewhere else.

[@quixoteyeah]

I would argue that the method is cheap and easy to write, and you should write it when you need it and not before. YAGNI. As software developers (as opposed to hardware developers) we have the luxury of continuous improvement. Even when you need it, you can add only what you need, and if you need it again take a good look at the design and maybe refactor. I ruthlessly remove unused code. Get it out of my head.

[@adambickford8720]

Its easier to add code than to change it. It'll be easier to create it when needed than conform it to what was predicted.

[@FlaviusAspra]

People think that making software easy to change requires a lot of work in terms of time. It doesn't. It's the little things. Like naming. Like the way objects are required to interact (invariants, preconditions). It involves a lot of thinking which with experience becomes fast, but it materializes in the code in little details which: Either point to the cracked door Or enforce a specific way to extend the code. Etc. But all in small details, not in huge structures or abstractions. A great, easy to change design, puts you in a mental model which, when you become one with, it's all easy and natural. As if you meld mentally with the ideas behind the code.

[@jimhumelsine9187]

I 100% agree that architecture, design and implementation are mostly the same. The distinction is in scope and detail. Unfortunately, design seems to get the short end of the stick. As for YAGNI, I like to reference the chorus from the song "Qué Será, Será": Qué será, será Whatever will be, will be The future's not ours to see Qué será, será What will be, will be We don't know the future, so don't code for it. But that future is coming ... whatever will be, will be. We can't avoid it either. While we can't design for a specific future, we need to be flexible enough to design for any future, and that's where your Cohesive, Loose Coupling, Abstraction, Modular, Separation of Concerns (CLAMS) practices make this possible. For me, learning and apply design patterns helped greatly in avoiding YAGNI while allowing for future flexibility.

[@kdcapparelli]

Evolutive prototyping, modularization, SoC, PoCs, versioning, DDD's context boundaries, canary (blue-green) dev environments, SOLID (open/closed) principles, Dependency Inversion/Injection, loose coupling (interface/contract driven), layers of undefinitions (facades, proxies) ... Too much too soon ? 🤔 I also think we should always have not only the primary and immediate goals in mind, but also a medium-to-long-term mindset. Something like the "code (or the software... the solution!) as a product", throughout all its lifecycle (inception, evolution, retirement...) and a good software-product portfolio management and governance.

[@boomerau]

You need to do the most complicated thing in the first in development - this is usually what causes cost issues. The number of projects that fail because they can't deliver the one required complicated requirement or worse go through endless redesign trying to achieve it where money is p....d down the drain on trying to get a bad design working not adding features. Some how "owners" find that one feature that if not understood will cause endless complexity and once you promise it are then set on it. Some rebuild is acceptable - constant totally rebuild with no new features not so much.

[@sam78ize]

love the thumbnail

[@pedroluiz2741]

Dave, what are your thoughts on Design Patterns? I’ve seen so many interviews where developers get asked a lot about all patterns from the top of their heads, and I feel like that we don’t really implement those from the ground up very often. That might just be my experience, I would like to see what more experienced engineers have to say about that.

[@ContinuousDelivery]

I use them all the time, and use them as a way of talking about code. I think patterns were an important step, I mean to do a video on patterns at some point. I don't recognise what you say in my own work, they just seem like a valuable tool of the trade to me.

[@joyfulprogramming]

I know you asked Dave but since you said you'd like to see what other experienced developers have to say thought I'd chip in. Your experience with patterns is very much like my own. They are limited in the vast majority of cases to head knowledge that never is exercised in a real codebase. And when it is exercised, the many misunderstandings become obvious. As an example, I used to work in a codebase where factories were often buried three layers deep - factories creating factories creating factories. Then outside the factories there would be lots of if statements. Clearly whoever implemented this didn't understand factories or they never got around to finishing their refactoring work. The same goes for code smells, connascence, Demeter's law, most refactoring ideas. The confusion is real!

[@pedroluiz2741]

@@joyfulprogramming I had a similar experience a while ago. I'm not saying that design patterns have no benefits, when done right, they do have. But we have a code base that is implemented on top of the command pattern, really great design, easy to understand, but we have bunch of implementations of each "command" every now and then due to how the business works. So a couple of developers thought it would be a great idea to on top of the command patterns "solve" the issue of implementing commands every now and then: Result: A big ball of mud, with a bunch of low level code, with a lot of if else statements to take decisions, that would take a looooooong time to understand if you were to start working on this code base. It ended up there for a couple of months some of us tried reviewing it and it is now thrown away... Lots of insights from this experience: not every time it is a good idea to introduce abstractions, sometimes the basics work better for maintainability.

[@evancombs5159]

Why not both? No reason why big up front design can't morph into incremental design. The key is just to not be wedded to the current design, and be willing to change it when necessary.

[@rmworkemail6507]

I've been asking this all the time. A whole philosophy and movement based on False Dilemma. This OR that. This OVER that. Well, that's poor thinking, you can pick both.

[@ContinuousDelivery]

Of course you can, it is just that you will have wasted a lot of time on the big-up-front design. I have built several pretty large, successful systems from scratch. It has been my experience that it is really not very long, once you have started coding, that you opinions change. So why waste time going into too much detail early on. My recollection of when we built one of the world's highest performance financial exchanges, was that we spent 2 days on the initial design, before we started writing code, and then designed continually for the next 5 years, first release was about 7 months after we started. Look at what SpaceX are doing now, their Starship hasn't got to orbit yet, and it is intended to go to Mars and further, they are at version 26, and everyone is a refinement on earlier versions. This is what real engineering, wether SW or not, looks like.

[@rmworkemail6507]

@@ContinuousDelivery most software projects are not SpaceX, that's a physical technology rather than a intangible one in first place. You can't blame Space X for the methodology either. Back to software: most software projects are known predictable product, known target user, known business rules.

[@matthewtrow5698]

I guess it really boils down to "continuous refactoring" as you progress through a new software solution - and that we just need to accept this as a _good_ thing. In my experience - and with my own mindset - it has been easily the hardest thing to come to terms with. I find myself _always_ looking at the "what if's" or the "what then's", instead of _just_ focussing on the "what NOW". To deliver _just_ the feature contained within a user story - and knowing that that user story may have multiple sub-tasks underpinning it. "As a user, I want to be able to select my country." As developers, we _know_ just how many sub-tasks this seemingly simple story generates. I guess it's up to us, in a sprint and series of sprints, to define exactly _what_ small iterative tasks are required to reach the ultimate goal of that story. Task one could just be the button that will get clicked. Task two could be the modal window - but that task, in itself, asks the question "do we need modals anywhere else? - generic solution?" The answer, I would imagine, would be "get the task done without a generic solution and focus on that later." But then, as a team, we need to remember to document that parts we _haven't_ built yet, to avoid incomplete threads of work. It is all too easy to work incrementally - but then forget DRY principals. That this simple story, really does require we address the core underlying functionality - the generics - and they don't easily fit into a user story driven development model. It's a very difficult mindset to get your head around.

[@kousheralam]

can you please add a summary section at the end of the video, also what you spoke is very hard to implement and continuously need to check are we going to correct direction or not.

[@ContinuousDelivery]

Every video has note associated with it. I always try to add relevant links where I can. Just check the description for the video. I have also just started a new Patreon community, if you join at any but the lowest level, you get access to something we're calling "The Modern Software Engineer's Companion - MSEC", it provides worked examples, descriptions and links to other sources of information, and puts some of my videos into context.

[@kousheralam]

@@ContinuousDelivery great

[@gronkymug2590]

Regarding 13:44. I loved doing this kind of premature design in the past, but now I am not sure it is good. It even makes things less readable and difficult to understand in languages like Java or C#. If we kept all these V2 constructs/classes in the same file I would accept it somehow as I would be able to quickly understand what is going on as I can see everything clearly. I would still argue that we don't need this change until we need it for some practical reason. Otherwise it just creates more code and more often than not, more files. It's like broken puzzles. You know how to put them together to understand them but you need to do it first. It is sometimes better to not break the puzzle in the first place and see the whole picture more easily. So in this case I disagree, at lest for the time being. I would like to hear about some more convincing examples. Maybe when there is a class with several functions and some of them relate to one responsibility while others to another responsibility. Especially if they don't all fit into one screen. Then such a split would look much more convincing. Embrace the chaos! :D ;)

[@Chisegh]

How do you design data structures? In my experience, having to change a data structure often requires big refactors. I have yet to find a good strategy for designing data structures with Yagni in mind.

[@bernhardkrickl5197]

Say, you have a data structure with a bunch of fields and one of them is some monetary amount and the next is the related currency. Those two fields clearly belong together and could be extracted into their own data structure. The question is, if those fields are of any concern in your application. If all you ever do is show the values to some user, it is probably good enough. As soon as you start doing anything with it, like adding up some monetary amounts, exchanging currencies, dividing money among people, a money data structure is immediately very helpful. The ideas of cohesiveness, separation of concerns, loose coupling, etc. come into play. Those guide you not only in defining your methods, functions, and procedures, but also your data structures. But you always need to think back to the problem domain and what you are trying to achieve. If it is not relevant to your problem domain, then you ain't gonna need it.

[@Chisegh]

@@bernhardkrickl5197 Thanks for your reply, those are some good ideas you brought up! A problem I sometimes face is, I don't need a Money data structure right now, but I can see a potential future where I do. However, I don't know if this future will ever come since priorities and customer requests change frequently. Now I have to choose: Do I create a Money data structure and prepare for a possible future, but also increase complexity, or do I not create the data structure since I don't need it right now and risk having to make a big refactor if it is needed in the future?

[@bernhardkrickl5197]

​@@Chisegh Another hint would be if the money fields show up at different places in your domain. Then you are pretty certain that you'll gain something by introducing a data structure. Eg. when you need to display the money in a GUI, or add it to some XML or whatever. Money is probably a bad example because it is so clear to us all what money is and that we will pretty certainly have to deal with it. Most of the time in a new domain area all the new stuff thrown at you just looks like random heaps of disconnected stuff. Ask your domain experts and users, maybe read books about your domain area to get a better understanding what it all is about. Soon enough, you will be seeing patterns all over the place. Then you need to make an informed guess which patterns are really fundamental to the problem and which are just coincidence and base your design decisions on the fundamental patterns. To a degree, you will always be guessing. That is while making small steps and getting feedback as often as you can is so important. You will also notice it in your further development: if solutions become hard and awkward to implement, your guess was probably wrong and you should try to change it asap. If everything becomes super easy, you're on the right track :)

[@dripcaraybbx]

Maybe my teams have all been structured differently, but as I'm listening to all this talk of design, what is the role of an actual "designer" in your experience?

[@leonardomangano6861]

Awesome video!

[@ContinuousDelivery]

Thanks!

[@disgruntledtoons]

To really create an app that's a big ball of mud, you need management's help. First, contract out the initial development, and tell the contractor to hurry. He'll slap something together using a framework. Check for basic functionality, end the contract, and put it into production. Second, whenever a new feature is envisioned, set a specific date for when it will go live, and pressure the developers to meet that date. Third, remember that re-factoring doesn't justify a higher price tag for your customers, but new features do.

[@karlgustav9960]

Sorry, but that is imho not going to lead you to the golden path in the middle between the gas factory and the big ball of mud. Incremental design only has a chance to work if you work with highly skilled professionals who have themselves a basic understanding of what best practices and standards exist, when to apply and when to avoid them. I worked with so many junior teams who claimed to work agile and never heard of principles like SOLID. Then the Yagni principle is just a cheap excuse to avoid any principles like separation of concerns or lose coupling. You don’t have to think miles ahead, but when walking in the dark along a cliff, you better think at least one step ahead. Sorry for ranting, but I am very frustrated with so called developers in their early twenties talking about yagni and digging themselves and their team directly through unmanaged technical dept into the world of pain (me coming from development now being in a UX or PO role)

[@anthonygriffiths122]

I feel your pain, a lot of older wiser developers do; when working with a young team

[@errrzarrr]

Thanks for putting this into words better than I ever could. Yagni is a poor excuse.

[@mikesurel5040]

You stole my comment. LOL. The maturity of the team matters a lot here

[@turn1210]

I actually felt your pain coming through in that message. And yes, maturity matters a lot here.

[@mabdullahsari]

That 1 "Its just a boolean" property randomly placed in a class that did not belong there still haunts me.

[@MartinMaat]

I would argue big upfront design is never the problem, it is big upfront implementation you may be wary about. The trouble with half-baked design in an evolving team is that less experienced or just time constrained developers will tend to extend what is there rather than to refactor. They will have enough trouble figuring out how it works now and build their solution on top of that. So if you as an initial designer don't carve the basics into stone, it is likely to grow into that big ball of mud. It all comes down to 1. the ability of people to recognize flaws in a design; 2. to understand well enough how it currently works to be able to turn things around while maintaining behavior; 3. to get the time to modify. Those are a lot of hurdles that get bigger in time. So you'd better make sure you do not leave any loose ends at the start, design-wise.

[@ContinuousDelivery]

I guess we will have to disagree pretty completely on that then 😉 I don't think that you get to build anything complex in the way that you describe. All good engineering is an act of exploration and ongoing design and refinement.

[@MartinMaat]

@@ContinuousDelivery We do not completely disagree, I agree with the continuous evolvement and refinement part. It is just that I have seen too much "refinement" of poorly designed systems. I think you will agree that mistakes in design are the most expensive kind of mistakes. The assumption that someone will fix these somewhere down the line in an iterative fashion is overly optimistic in my opinion and experience.

[@ContinuousDelivery]

@@MartinMaat well, it's the only way that things get fixed. Designs evolve over time, if they don't the system is simple, if they do, then you need to be able to sustain the ability rot change them.

[@manuelgurrola]

Dave, it sounds like you're working alone. How can I make sure that this approach and ideas are implemented by all members?

[@ContinuousDelivery]

It's about build a culture of experimentation and exploration. I have done this a few times, at a few different scales. It's not easy, but is very rewarding when it works.

[@aslkdjfzxcv9779]

when i design "in the back of my head" while listening to a problem, i'm doing a simple "feasibility" study.

[@ruixue6955]

1:56 anti-pattern: big up front design 2:17 2:31 YAGNI - 2:36 came from *XP* 3:55 4:42 recommended way of design: go to a few different stages when thinking about design 4:48 think about feasibility 5:02 try the process of trying to find the simplest thing 5:13 at this stage, the conversation is about exploring and understanding the problem 6:17 as the problem is being explained, we *run it through a mental model* 6:44 a simple diagram, or anything else 7:32 get firmer validation about our thought 7:56 start to figure out where is the wrong 8:00 XP: we want to focus strongly only on solving the problem in front of this 8:40 *make progress incrementally in tiny steps* 9:44 example 10:21 YAGNI - 10:35 at the first step, it is no big deal to put everything into a big class, 10:41 the problem:it doesn't take too many more step before it starts to become a pain

[@davidteague3849]

Great software comes from disciplined teams that embrace a little refactoring pain every day. If your refactoring doesn't have the slightest pain then you have to ask yourself if you've over designed

[@V3ritas1989]

How to get out of a big ball of mud?

[@jangohemmes352]

In short: The Boyscout Principle - leave every bit of code better than you found it. On top of that: test all new code you write (i.e. don't ever add more mud) Maybe it'll feel like you never get out of the mud, but this is the only way to clean it up bit by bit in those areas that it matters (the areas you actively work in)

[@jimhumelsine9187]

One shovel load at a time.

[@revietech5052]

IME, I've found you can leave things in a better state than you found it but will always find things in a worse state than you left it.

[@cod3r1337]

@@revietech5052 Then there's something wrong with your team's culture and/or some team members are lacking crucial skills. I've been in that place for the first few years of my career, and it's incredibly frustrating. You basically have two options: Educate your teammates towards more professionalism (which may or may not succeed, depending on talents and social dynamics of the people involved), or find a new team or workplace. I eventually managed to overcome this situation through a mix of the above, but that was a long and bumpy ride.

[@NoyaD9]

First: cover the mud with unit tests Second: refactor

[@PaulSebastianM]

Incremental development is sometimes confused with incremental design. It's just as bad as BUFD.

[@ContinuousDelivery]

In reality incremental design is the only form of design, for anything complex.

[@vimalneha]

When I see your videos, your extraordinary work in CD book comes first in mind! But I am not convinced by your arguments at all, it is the recipe for Big Ball of MUD again. Today in the cloud-native era, one has to fully factor in expected users of 50 or 500 million. If one doesn't know. He / She should do other work or must have philanthropists to fund such experiments. We are in a time of operational excellence that is more than the sum of the Software development, which I mean coding. We had functional decomposition (time and sequence-dependent) that failed the world. Then we looked for Domain-based decomposition DDD, again not a great design consideration, but magnitude better than functional decomposition. But we still design against requirements. What if the requirement changes, will we change the design? One has to understand the CORE-Use case, the essence of the core business. Just like our body has 6-7 core organs that handle variation across the globe, geography, culturally. One has to understand ROI on the Software side designs or the operations side and it depends on the maturity of the team on which of them lies their strength. Second, the crux remains the ability to design composable architecture by identifying what will change over time and abstracting them away as a service. Stateless and message-oriented reactive architecture on the software design side and corresponding operational readiness are very important issues that might need a month to understand once we have done the requirement gathering and the core use case identified.

[@anthonygriffiths122]

naive flandering - lol love it

[@benr3346]

that shirt was distracting ! i need it

[@ContinuousDelivery]

You can get it here with a discount, as a viewer of this channel: www.qwertee.com/?

[@softwareminimalist]

All this brittle infrastructure oop requires does not exist in FP languages. It’s difficult to program yourself into a corner with FP . It’s easy to create a ball of mud with oop. Death by verbosity and explicit structure.

[@ContinuousDelivery]

This is nothing to do with OOP, this is about coupling, and that is wholly unrelated to programming language or paradigm. If your registration system knows how your order management system works, both are broken.

[@kayoscreed]

"Designing" a ball of mud ^^

[@rmworkemail6507]

I wonder why Agile evangelists are so design - phobic? Why do they hate (or fear) so much someone takes to properly think about what could happen in the near future and put in place well known best-practices. This is completely anti scientific and unprofessional.

[@karlgustav9960]

I don’t get it either. Only solving the problem ahead of you will cause more problems ahead of you that will… it’s a sure way into massive technical dept. because makeshifts last the longest. Overengineering certainly is the other extreme, but thinking two steps into the past AND the future will not completely ruin any kind of comprehensible architecture.

[@JorgetePanete]

Sometimes the Agile managers or however it's called do not know about programming or how much time something takes :(

[@mwildam]

Oh, and anyway most go with what is known as "the best practices". They decide whether to use stack A or stack B - maybe stack C, that's it.

[@alexsarbu3978]

To say that "Agile evangelists" - and by that I assume you mean people like David Farley, however that's not how I'd call him - are design-phobic is a gross misunderstanding, and a terribly misinformed statement I'm afraid. He *never* says to give up on design; on the contrary, working iteratively means designing iteratively, as you figure out more pieces of the puzzle. You never stop designing; instead, you do it at the right time. On the contrary, upfront design doesn't work well; because you simply don't know enough of the problem you're trying to solve, nor how to solve it.

[@m13v2]

which agile evangelists would that be?

[@Immudzen]

I think my normal approach to design is to look at what people need to accomplish, what they would like it to accomplish, and what features they would like to add to it over the next year or so. From that I try to break it down into some high level ideas based on the math that has to sit behind those features. I look at what math is in common and for that part I try to figure out what I will actually need because often that ends up determining how other parts of the system will need to function and it also doesn't take more than a few hours usually. After that about a day is spent on trying to break the system down into some high level modular components and we try to work through the design quickly to see if it can cover all the usage cases. Once we are to that point we can start coding. In general the classes all have to be small, we try to use pure functions where possible, and use dataclasses for interfaces. This makes writing the testing much easier.