How To Avoid Big Upfront Design

[@MohammedElotol]

"A minimum viable product (in software) is not a mess of code that barely works, but a well-done piece of software that is perhaps missing some of the features that would be necessary to call it 'done' or 'ready' from a business perspective."

[@ContinuousDelivery]

💯

[@sewera.account]

The best time for me to see this video was over a year ago, when I started my over-engineered project for my B. Sc. Thankfully, the second best time is now, when I have many more projects ahead of me.

[@tudz123]

10:33 Please don’t get tired of reminding us! Had a good lol when I heard it 😂

[@arturk9181]

10:33 hahaha that caught me off guard!

[@travispulley5288]

I just watched his advice on the subject previously, so I was ready for it (see kzbin.info/www/bejne/op3EhnV-atSUr9k )

[@robwatson826]

How often should we test? "All the f***ing time" - Dave Farley, 2022

[@travispulley5288]

[@jimhumelsine9187]

Yes. Yes. Yes. Yes. We can't predict the future, but we can't avoid it either. I often quote the chorus from "Que Será, Será" as an metaphor: Que sera, sera Whatever will be, will be The future's not ours to see Que sera, sera What will be, will be We need to design our code to be flexible enough for any future that will be, even if we cannot see it at the time. Design Patterns have always worked well for me in trying to achieve this.

[@ronylev-ari3219]

another great video and I really appriciated the concrete example of a design problem and the thought process involved when approacing it

[@hannesvanniekerk2256]

Rewatched that f-bomb drop 3 times :D Uncle David keeping it real in another great video.

[@somewhereinyorkshire4782]

Great video. I am reminded of a quote from Michael Jackson (The programming guru of old, not the singer) who said something like "Don't work on detail unless you're really good, in which case, don't do it yet"

[@devsuvara]

Excellent info Dave!

[@BryanFinster]

19 seconds in and it sounds like Dave is quoting me. I must be on the right track!

[@brownhorsesoftware3605]

I always start with the UI which keeps you on a track of making the fewest assumptions as well as additional insight into the functional design. The initial design is the simplest list of the tasks the software needs to accomplish which grows as you work on (code and run) the software. You always build on what works so writing test code is superfluous. The backend can evolve independently and your backend bugs are immediately visible. I don't know if my process has a name. 😀 Your video has inspired me to formulate something I just took for granted.

[@hypenage2415]

I think youre right for this design pattern and I practice the same when making software. Steve Jobs once said “youve got to start with the customer experience and work backward toward the technology, not the other way around”

[@mx-hx]

Interesting idea, but "writing test code is superfluous" is a big smell. There are tons of reasons why TDD / BDD are currently considered best practices (not widely implemented properly, but widely dreamed about by devs with aspirations). If you do write up your method/practice in depth, do let us know where to read it. If you've really found a way to develop software better making testing superfluous, I want to think about it deeply with you 🙂

[@brownhorsesoftware3605]

@@mx-hx I did not say that testing is superfluous, I said writing test code is superfluous. That is because the production code IS the test code. On the contrary, the code gets more testing because you always run the final code, not a generated test based on a possibly false assumption.

[@Gemasted]

Upfront design when the parameters are unknown is definitely something to be avoid. However continuing on evolutionary designed code when the problem is well understood can be just as problematic if not more so. I've seen countless projects where people tolled on a hard to maintain system for years just because you "shouldn't" do a big refactoring, the most successful systems I've seen are systems where people rewrite and redesign it completely upfront from scratch one or two times.

[@BryanFinster]

How do you know the problem is well understood?

[@Gemasted]

@@BryanFinster because you've written the system already :)

[@errrzarrr]

This, exactly this

[@BryanFinster]

@@Gemasted I’ve frequently seen that not matter. :)

[@hipvivid]

Isn’t rewriting it from scratch what we’re trying to avoid here? If we now know how it should be designed to reduce maintenance pains then we should work to refactor those portions of the code that are causing us issues. If we ended up with a big ball of mud and a huge amount of technical debt then this is surely a case of not taking enough care to refactor as the project progressed. This shows the importance of refactoring as we go along so are design isn’t hindering our ability to change and maintain the software.

[@krumbo]

Hahaha, just shared this video with another branch of our company. They always start as Big Upfront Design and then stuck because just crazy complex. Like stuck every time.

[@thmstbst]

I recently interviewed at a job that said they were using tests, but they only seemed to use them to assign work. What I mean by that is team leads would write the test, then pass it off to someone else to complete the feature. They seemed to have a lot of custom functionality for individual customers too. If I end up working there, how should I adapt? I guess I could write additional tests, but I would be worried about being seen as creating additional work.

[@BryanFinster]

Honestly, I wouldn’t work there if that’s how they work.

[@thmstbst]

@@BryanFinster thanks for replying, I'm sure that's your honest opinion. I guess I'm just trying to think through why it's a bad idea. Some places are similar in that a manager give requirements, as a go between. It's just not in the form of a test.

[@BryanFinster]

@@thmstbst both of those are honestly terrifying to me. I’ve heard of places like that, but that level of micro-managing destroys product value and the souls of people working there. It’s one of the worst anti-patterns that exists for value delivery.

[@gamer-gw9iy]

@@thmstbst I guess it depends what kind of tests they are assigning, if it's super high level (which I doubt), you might get some (little) breathing room. I'd work there only because I'm only going to be working for this summer before I continue school😂

[@ContinuousDelivery]

I probably agree with Bryan, If these tests are high-level "executable specs" for a feature, as @gamer describes, that only say what the user should perceive at the end, then fine. If not, this really won't work well. There are lots of places that try to write SW this way, but they aren't very good at writing SW! If you have a choice, I'd look elsewhere. If you don't don't worry about adding more tests, because this is how you write good code faster, so it isn't "additional work" in the long run it is significantly less work.

[@m.x.]

1) "If the only tool you have is a hammer, you tend to see every problem as a nail." Big up-front design is not dumb at all when the requirements, size/complexity and context tell you so, 2) the true technological, scientist and mindset revolution wasn't during the mystified Enlightenment, but rather the Renaissance with the discovery of America, 3) SOLID, High Cohesion, Low Coupling, SoC , DRY, KISS, YAGNI, etc. are concepts that have been around for quite a long time, most developers just don't understand or know how to apply them.

[@Immudzen]

When working on any kind of simulator the one thing I think you have to do upfront design on is the actual math. What are the actual equations you are going to implement and why are they the right ones? This is such a foundational issue that it ends up touching a lot of the stuff the software does and while you can change it later it can also be quite painful.

[@DinkarGuptaDG]

Toyota improvement kata in actual form for us engineers

[@finne-dich-selbst-3395]

"Much of present-day software acquisition procedures rests upon the assumption that one can specify a satisfactory system in advance, get bids for its construction, have it built, and install it. I think this assumption is fundamentally wrong, and that many software acquisition problems spring from that fallacy. Hence they cannot be fixed without fundamental revision, one that provides for iterative development and specification of prototypes and products" - Fred Brooks, No silver bullet, 1986 Only that currently we might be mistaken to think that something we have coded is ready. It will never be if we are able to learn, since learning changes our understanding, and should change software also. It would be great if these changes would be easy to implement.

[@ContinuousDelivery]

💯💯Exactly my point! I think that the only sensible approach is to start out assuming that we are probably wrong. That focusses us on being more defensive, and so, when we find out how and where we are wrong, we can easily fix it.

[@karlgustav9960]

This is all well and true in a world without graphical user interfaces. However for an e-commerce web site, users who hate your „first step“ will just not come back for further iterated versions. Sometimes first impressions do matter. That’s why disciplines like User Experience Design do exist. It is the UX Designers‘ job to design and test before things go into production. Sometimes several iterations go into a solid design doc that is handed to development and is then misunderstood and frowned upon as „big upfront design“ and important parts of it are ignored or changed at will out of ignorance or a false understanding of agile practices… I’d still say leave the design to the designers and the engines to the engineers :-)

[@mx-hx]

You are confusing visual/ usability design of the UI with structural/modular design of the codebase. To follow your analogy, you need both an aesthetic designer for the car body, but also a technical designer to make the engine blueprint.

[@TjSpoonManJacques]

Awesome!

[@NickDanger3]

Dave, The foundations of modern science were laid in the middle ages. The “enlightenment“ was merely an ideological accretion on top of that foundation, and has nothing to do with science itself.

[@ContinuousDelivery]

Not really, one of the key ideas that gave birth to science was that decisions from authority are not guarantee. This was firmly an enlightenment idea. As feynman said, "science is the belief in the ignorance of experts". en.wikipedia.org/wiki/Age_of_Enlightenment

[@Sergio_Loureiro]

10:32 "Test all the fucking time". No shit, Sherlock!

[@jamesgg9950]

Keeping your design options open is great until you realize your last project's server code is still running SQL on CSV files because you deferred choosing a database.

[@ContinuousDelivery]

...but since you were keeping your design options open, this should be a simple fix, of course, if you were keeping you options open, the SQL wouldn't have leaked outside the persistence code 😁😎

[@motyakskellington7723]

not knowing what you want or keep failing at getting what you want

[@foad-esad]

I love it .... test all the f&^king time!

[@mabdullahsari]

I work in a team that gets scared when I define anything that ends with the suffix "Interface". ¯\_(ツ)_/¯

[@krccmsitp2884]

Then choose another suffix, e.g. Contract, or choose another team. ;-)

[@mabdullahsari]

@@krccmsitp2884 It'll probably be the latter haha.

[@BryonLape]

Evolution is random, undirected change.

[@sergmmm]

👍

[@way.journey]

Unless you are Mozart

[@MisFakapek]

We need more code. There are too many words but not enough code. I feels like someone explaining how V8 engine works with tubo-charger without showing a mechanical schematics of how it works.

[@ContinuousDelivery]

kzbin.info/www/bejne/op-XiKGujZKqqNk

[@gamer-gw9iy]

The difference between a mechanic and a developer is that the mechanics tools will rarely change 😅 Only code that would be easy enough for most aspiring to learn some software engineering would probably be some really simple Python, but I doubt much Python will be used in 30-40yrs.. Teaching without much code will keep these lessons useful forever and for everyone 🙏

[@mx-hx]

You might need more experience, then you won't need the code to grasp & apply the concepts.

[@pvtjoker3833]

What does not work: Teams of "architects" that are not developers (no real experience) and don't test what they propose. They are total idiots proposing "designs" that are fundamentally wrong. Corporations need to wake up and stop having these useless "architect" groups.

[@ContinuousDelivery]

Yup, I talk about architecture here: kzbin.info/www/bejne/e52wn3t6iKuUedk

[@mx-hx]

Do you work at my company? 😀

[@mikeguantonioify]

100% Agree!!!

[@bc4198]

There's something fascinating here where the things that get published are the things that get finished, with the side effect being that they are less evolved. They were able to finish because they stopped getting better ideas...