Agile Architecture Part 1 - Allen Holub

Breakout session from Software Architect 2013
software-architect.co.uk/
'Software Architect' is an annual technical conference for software architects and software developers. Featuring both full-day workshops and focused 90-minute breakout sessions, our expert speakers will ensure you and your team understand the fundamentals of software architecture and are up to date with the latest developments, ideologies and best practices.
Please visit software-architect.co.uk/ for information on the latest event.
-------------------------------------------------------------------------------------
'Software Architect' is part of DevWeek Events, a series of software development conferences and workshops, including the flagship DevWeek conference (devweek.com/), brought to you by Publicis Blueprint.
-------------------------------------------------------------------------------------

[@nekrivonozhko]

Thank you very much, great class

[@LukeAvedon]

Wow. This is freaking amazing.

[@Don_Giovanni]

How the tides have turned. C# is getting pretty popular nowadays. (WPF still sucks massively, though)

[@matthoffman6962]

I think he’s moreless right about getting user feedback and getting them more involved in the process over deadlines. Unfortunately, most businesses do not run this way. They deliver a product and define a scope and budget. Then, when you go through the process you’ll get that customer feedback and if you accept that feedback it will either push out the scope or you’ll close the actual project but then work with the customer after.

[@MrC0MPUT3R]

This is the most frustrating thing about being a developer. I ask my Product Manager - the person whose job it is to talk to the customer because they don't trust me to do it - what our customer wants and thinks about the feature we're building, and I get blank stares. I think about half (at best) of the features I've worked on in the past 2 or 3 years actually got _any_ use from customers. The rest got a lukewarm reception. Yet, during the development, you'd think those features were the most important thing since sliced bread. Meanwhile, we can barely work on the features because the product is constantly on fire due to all the feature work.

[@BryonLape]

I find that most companies do some horrific version of Scrum, claiming to be agile.

[@rafaelnunes000]

Allen Holub is a genius!

[@buscadordebaru]

True

[@phyzix_phyzix]

How do we get the customer in the room during development? We would have to hire that person. Otherwise they will lose their current job. If we hire them and they were using the software as part of their old job are they still a customer?

[@julkiewicz]

Yeah, I'd be very curious to know that as well. I couldn't imagine such a scenario. Besides if a "customer" is consulting for you all the time, then that becomes their job - instead of whatever their job was before. So effectively they become useless to you as a consultant.

[@aeggeska1]

We moved to the customer.

[@phyzix_phyzix]

@@aeggeska1 Can you elaborate?

[@rajadas6432]

US bank rewrite their entire small business lending process in 2017 and they actually brought in real customers on certain cadences. Net result, they delivered something valuable in 4 months which was supposed to delivered in 2 years. If we can’t bring customers in, we need to bring customers voice in. A person who will frequently meet, see, feel, emphasize with customers and bring that information back to the team. Other possible way, incorporate numerous customer feedback loops within your decision making process. There are other ways as well. The whole idea is the work must be based on customer feedback.

[@EmilNicolaiePerhinschi]

if data does not matter, why have classes or objects ? why not use modules and structs ?

[@MarcusNielsen82]

Personal reflection using TypeScript: Interfaces and class constructors help hide certain details from the code that depends on some behavior. You can replace a constructor with a higher-order function and get the same effect on fewer rows. You can create something similar to modules and use something similar to structs (both objects in JS/TS), and that should be totally valid. But you might have a harder time to play nicely with the notion of interfaces. In the end, if modules and structs work for you and your team, and you hide the private stuff, go for it! It's about abstractions, not classes.

[@StreetsOfBoston]

Dependency Inversion is always a bit difficult to explain, describe. I see it as follows: Instead of your class depending on the *implementation* of another class, it should depend on the *interface* that that other class implements. The interface is defined by the same module in which *your* class is situated. Why: If your class depends on the *implementation* of another class, a change in or replacement of that other class may need a change in your class as well. With the introduction of the interface, you introduce stability, the promise that the interface is implemented according to that contract, no matter who implements it or how it is implemented. (Dependency *Injection* is then used to manage the Dependency Inversion, providing your class with the correct/configured implementation of that other class).

[@matswessling6600]

thats not right: dependency inverson is when you invert the depency relation: code in dependent modules call code in independent modules. You inject code in your drpendent module so it can call it whenever it want.

[@axelvanhooren6325]

If we always complain that "the business" doesn't know what it wants, why do we always ask them what they want. Are they able to know what they need? Do they have the knowledge and competencies for this? Do they have skills to solve information problems and design information solutions? Is that their business? Maybe that's the point we missed for decades. Upfront design doesn't mean frozen upfront design. Requirements are statements to which the solution has to correspond. It has never been intended to base the design solely on the requirements. The set of requirements are simply not enough. They are useless without broader contextual insight. A team lacking this broader insight doesn't know what it is doing. etc. etc.

[@aneshas]

Yes, it's actually about "how much" up-front design is optimal (you have to have some).

[@zofe]

When the business is MBA, then shut it down and return the money to the investors

[@BrasingtonAssociates]

This is also why products like JIRA don't support the way you are describing work is done. The "broader context" cannot be easily communicated solely with stories.

[@MrC0MPUT3R]

I've stopped asking what people want and started making suggestions on how to do/design things. People, businesses, customers, etc. don't know what they want, but they know what they don't want.

[@softiceable]

He came up with Holub Replacement Principal because nothing else existed to convey it's intent. To me it sounds similar to Liskov's Substitution Principal. Whether you change a class implementation radically or you substitute a class for another, it should have no side effects on the client code.

[@PatriceStoessel]

you're absolutely right. No idea why he didn't talk about Liskov's Substitution, since he knows about it (Liskov's Substitution is present on his slide at 49:50)

[@TalkingBit]

He talks about changing the internals of a class not affecting users of that class. Liskov is about the behavioral equivalence of classes in a hierarchy.

[@gspolima]

I think the liskov substitution principle is more about, let's say, changing from working with a list to a dictionary shouldn't matter because you're interacting with a Collection, a much broader thing that encapsutes both of them.

[@fennecbesixdouze1794]

They have nothing to do with each other. HRP is about dependencies, LSP is about subclassing.

[@malteneuss8058]

It's interesting to see how he suggests we should do OO-programming, which is much better represented by non-OO programming (or at least how OO was intended by its inventor Alan Kay, without classes and inheritance): "Tell, don't ask, send messages", this is precisely the Actor model in Erlang or Scala. "Minimize side-effects of a class to zero", this class then becomes a function so better use Functional Programming like Scala or Haskell. "Minimize the interface you depend on", again this then becomes a single function type declaration....

[@fennecbesixdouze1794]

Actors are stateful, there's nothing functional about the actor model. That being said yes, many values of code organization and programming practice are shared between OO and FP styles. And OO consultants know this, Bob Martin for example does all work in Clojure now precisely because it has better support for FP paradigms. But consultants also have to remain employed, and nobody is hiring FP consultants, so they call themselves Agile consultants or Object Solution consultants or something else. It's just marketing, a non-technical manager will hear about "objects" and have it explained to them that it means "now you can pay for software once and then reuse it all over the place", and that sounds great to them because you're claiming it will save them money. Good luck trying to explain functional programming to a non-technical person, they most they'll get away is that it's somehow mathematical.

[@anthonydelgado510]

19:01

[@davidlamb1107]

20 minutes in. His point about OO and getters/setters is fine. But his comment about C# only being of interest to the large corporations did not age well.

[@rfphill]

I was gonna post the same. I thought there would have to be someone else who chuckled at that... I do agree with his sentiment about Microsoft but I stopped being embarrassed about being a fan awhile ago. I think since this presentation,7 years ago, Microsoft has evolved a lot.

[@soberhippie]

One thing worthy of pointing out is that this talk is about statically typed languages (as far as the interface part is concerned). When I see people writing interfaces for python classes, it makes me want to self-harm.

[@julkiewicz]

The reason he cited (to separate "business logic" from "presentation logic") is not the reason why MVC is used. It is rather to separate business logic * STATE * from the presentation * STATE *. People perhaps sometimes shorten this idea and omit the "state" bit, but that's what it is about. And the reason why this separation is important is because it directly affects user experience. When state is stored in the wrong place, your application will have subtle bugs and weird behaviors that will absolutely affect your users. You don't want the position of a scroll bar to persist a refresh of a component - it looks weird, it feels weird. Similarly you don't want your business state such as user preferences to be forgotten and not carried over to the persistent storage. Moreover, having those states separate allows one to have multiple presentations for the same piece of business logic, something that's very common and very useful (to *USERS*).

[@matswessling6600]

its not just state. Its also the actual code. Presentation and business logic is to separare that doesnt necessarily change together.

[@davidp.7620]

The point about cloud aged like fine... Milk

[@julkiewicz]

Another completely bogus claim is that software architecture should always mimic 1-1 whatever domain it is modelling. Software runs on hardware, not on fairy dust in a magic land. And hardware has limitations, performance considerations, bottlenecks. I can certainly see appeal of trying to tie into the actual domain and not inventing new names for things that already have specialized names used by the people working in the domain. But what is proposed here is certainly going way too far. There is nothing wrong with sometimes using abstract concepts, patterns. The way he describes OOP is how people were thinking about it in the 80's. To say it is outdated it to be merciful.

[@tomvahlman8235]

Technical considerations should be described in the high level architecture (HLD) but that may not be the same as a domain model, describing mostly business components. What is meant here are "essential complexities" i.e. the business logic, as it is implemented in code. Hardware, queues , databases, connection pools, thread pools etc are ”accidental complexities” and should be isolated from the ”essential complexities”. This talk is as good as it can get and the way he describes OOP is certainly not outdated as SOLID is a very important design principle. I have been convinced that using TDD is the way to go since last year, so I wanted to delve a little more into this subject, as this perspective is hardly mentioned in this talk. Using a well known domain model, using 1:1 name conventions in code vs the domain model, will guide developers writing ”executable” specifications, high level JUnit tests written before actual implementation code. Writing high-level tests this way expresses business requirements clearly so developers knows what to do before starting coding. Then coding TDD-style, from the tests, will guide a developer to write code that adheres to the SOLID-principles as well, meaning end-result will be code that is easy to change and extend. You should test-drive at the API level and not against lower level like class-methods, as this will tie test to implementation details. Lower level code will also be tested when the higher level API is tested. Provides a link to a Farley-video which explains very well about TDD and "test driven design". kzbin.info/www/bejne/op-XiKGujZKqqNk

[@geertdepuydt2683]

nothing you can't find in a few Wikipedia articles on the topic...

[@Hector-bj3ls]

The SOLID principles are terrible for maintenance and performance. So if you want slow, complex, abstract, over engineered, tangled messes of garbage then by all means.

[@zebmason6530]

Watching this was a waste of time, I did think about terminating during the first 10 minutes. The usual Agile == Scrum arguments, lots of talk about web stuff which wasn't relevant. A well defined interface is quite possible in procedural code so why go on about OO, after all OO is too low level to be architectural...

[@BryonLape]

Scrum is not agile. Allen even says as much in the first 4 minutes.

[@alexanderroddis2049]

@@BryonLape Carefull, dont feed the troll!

[@m13v2]

i agree to your first sentence. next time try listening. you will enjoy it much more. the talk is amazing.

[@tomvahlman8235]

This talk is better than most. He described tell dont ask principle in a pedagogical way. He mentioning important thing never ever add anyting to your code that is not needed (always use TDD) The examples regarding SOLID principle were important stuff, but may be not anything you grasp at the first time.