Greg is the person who has the biggest influence and motivation in my IT career, and Dave is hosting one of my favourite RU-vid channels. Thank you for setting this up, gentlemen!
My first professional coding project was an RS-232 driver written in Java for a RFID reader. The biggest thing I remember about it was the lack of unsigned byte in Java. Funny how these kinds of things change slightly but never really go away. I try to think about that experience in the context of what kind of challenges people are solving today that will be passe in 20 years, given the advancements in abstractions and everything. I could picture an entry level programmer having to write something today using a platform or service but needs to be able to troubleshoot and learn how to figure out an esoteric bug with a library they are using, and having to navigate the back and forth of an issue report and patching it themselves. That is the path towards that higher level of thinking that makes someone a capable architect or master engineer... Whatever we call it. Thanks for the great conversation
About "Meaningful language" and "Problems not Products": Great part of the discussion/video! There are a number of layers of 'translations' needed from the business/user problem you need to solve (Problems), expressed in business and user terms, all the way down to the technical implementation (Product). Each layer has its vocabulary and proper mappings between the layers and vocabularies are needed. It's much like Dependency Inversion this way. Describe *what* you want to do in one vocabulary (contracts/interfaces) and then choose *how* to implement that contract which may use an entirely different vocabulary. Delay that decision of implementation (don't worry yet that 'water' consists of two Hs and one O). Remove that complexity of actual implementation from the contract/interface. Then dip into the implementations (and go back up) to validate the implementation. Of course, don't go overboard. Don't over-engineer/over-design it with too many layers. Getting the balance right is an art :)
Gregor said: "Any line of code that is not deployed is cost" so what about the code of unit tests then? I think many unit tests are useful but there are also unit tests that are not worth the cost of having them and we should delete them right? Especially we should delete many London style unit tests because those hard to understand unit tests are terrible for projects right?
I totally agree with Dave Farley that "quality in modern systems is our ability to change them". On the other hand London style unit tests use many mocks implemented by hacky mock libraries that are hard to understand and they easily break when changing the internal implementation despite the functionality remains the same. London style unit tests make the system much harder to change yet Dave still thinks London style unit tests are useful. What do you think?
If your software is of poor quality, it might not live long enough to benefit from the ability to change. So, tests are critically important. But I agree that tests should be as easy to change as your software. They should refactor with it (which, in most cases it can) and when needs change, you'd change the tests first.
It’s funny and not wrong, but also not useful. I’ve always preferred Fred Brooks’s definition that architecture is “… designing to meet [users’] needs as effectively as possible within economic and technological constraints”. It’s all about making the tradeoffs that benefit users.
Communicating architect's vision on how should we preceed managing complexity of a particular system is very hard. We may explore this more in the future.
I just watched a GOTO video by Gregor recently. He's got a great mind, and I appreciate the insight as it helps confirm that the thoughts I have regarding architecture and practices around it aren't my own new concepts but something we come to understand through the experience of learning.
Thank you very much for these very interesting interviews, the knowledge, experiences and perspectives that you "deliver" are reallly appreciated. Thanks!
Yes there are several rugs that we should pull from programmers. One rug is trying to use TDD everywhere. The other is mocking everything outside the class under unit test and another rug is using mock libraries... I believe good unit tests are the next step in making system that are easy to change. Unfortunately right now 90% of programmers don't know how to write a good suite of good unit tests.
I see where this comes from and I've written (and in a way still have to) tests like that. This especially happens when you retrofit tests to existing code, don't hide enough detail or don't refactor. I find myself writing tests that test more on a ceptual/behavioral level rather than ones that break with the slightest change in implementation when I go test first or interface first and refactor until I think the interface of the module is as simple as it gets.
Nice podcast here, but I struggle with the idea that nobody seems to know what architecture is. how can we start the discussion if there's no definition? It seems like there are ideas of what we want the term to mean, so we should start with those until we can isolate what is common to everybodys 'ideas', so that we can get a true definition, at that point we can start having the real conversation
What is a coffee mug? Does it need to have a handle? Is it made of ceramic? Is it still a mug when it holds half a liter or more? What if you only pour water in it? Reality is often blurry but still we usually can talk about it quite well. We can ask for the cup and will be handed the mug (unless it's next to one without a handle, one made of glass and a tiny toy cup), right? Good definitions are hard.
@@black-snow While it is true that good definitions are hard, I feel that your position here leaves us with nowhere to go. If it is impossible for us to define architecture in a satisfying way then the word might as well be done away with too. But if there is a commonality between what software developers think when they discuss 'architecture' then we could use this as a starting point for the definition. This is why i suggest we look at what people want to describe when they say 'architecture' so we can figure out what we want the term to mean. I've not got a satisfying rebuttal yet to the coffee cup analogy as its a fundamental problem
See IEC 62304 for one brilliant way to define and make architecture, which conflicts with Greg's statements, or basically conflicts with almost everything he says.
It’s like when during an interview interviewers ask what AWS services are used for. And what is the bandwidth. And you’re like, “well, we needed postgres, we took postgres, we needed pubsub, we took pubsub, everything worked, no one seemed to complain.” So which AWS services did you choose for this project? And you’re like, “no idea, they’re mentioned by AWS name in two or three files out of a million in my project and few more times in my CV because it's fashionable and in most companies no one cares about it.”
A thought came through my mind a while ago and looks like true in most of the cases. As in Taoist philosophy yin and yang conjure each other, and these are opposing forces. My interpretation in software development context is: From restrictions comes freedom!
If an organization can benefit from a dedicated architect, the prime directive of the architect should be to make sure that the organization no longer needs an architect.
Regulations on software development increasingly require continuous maintenance of software architecture, and thereby requires architectual competence with software product manufacturers.
