"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."

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.

10:33 hahaha that caught me off guard!

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

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

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.

This is one of the best videos I've seen. I find myself constantly fighting against my fellow developers tendency to impose design rather than allowing ourselves to discover design as we go along.

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.

Excellent info Dave!

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"

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

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.

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

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

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.

"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.

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.

Toyota improvement kata in actual form for us engineers

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 :-)

"The Unix Way": Do one thing, well. Discoverable text interfaces between parts. Scripting. Deliver the correct result first - The chrome of its presentation, later.

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.

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.

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.

Awesome!

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.

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

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

Evolution is random, undirected change.

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

Unless you are Mozart

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

👍

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.

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...

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.