Metrics always "escape" to management.

I think Gojko has seen a lot and has more to say but time is a big constraint. I wonder how is like to work with him. I really like people discussing how things works under the hood instead the just it works kinda devs

De-Coupling, Strangler-Pattern, Microservice... is this just innuendo of some smart ass or do we have architectural patterns in social relationships or should I stop projecting?

Very informative 🧠

Over my career I have swung on both sides of this debate. I think there are elements of the industry that are arguably in the bracket - to be honest down in the system, near the hardware and similar embedded systems. However for most of us, I think craftsman (ignoring the lack of gender neutral name) really is more appropriate. Perhaps though it is our model of what a craftsman is that causes us to reject it. I think the nearest we are is to the medieval stonemasons who build cathedrals. There was a standard approach they could alter based on there own and "customer" preferences, as well as site specifics. They worked in teams - it was not a one or even two person operation. Basically there was heuristic knowledge of what (usually) worked and that most would follow. Every now and then, someone would have an idea on an improvement. Sometimes it worked. Generally what they built stayed up but it was based on experience. Compare to now where there would be architects who would design it but would consult structural engineers who would probably generate a model the system but least do lots of calculations based on scientific knowledge of the materials etc. Different engineers, with different skills, would actually build the thing. In our approach we are much nearer the medieval masons than the structural engineers.

It's FTSE all the way down

3:35 Who doesn't love stock videos, let's take a look at what is happening around 7th line from the bottom of the screen 👀😆

I came here to hear the words dependency injection/inversion. Let's see if I get my wish...

Thank you so much for this clear communication This is nothing short of brillant, extremely important and widely under appriciated

Did you ever read the classic Yourdon & Constantine's "Software Engineering"? He covers this issue, making it a point to avoid at all costs "pathological coupling".

I'm glad you're doing this video. I've been a programmer for almost 25 years and I just heard about Coupling and Cohesion a few months ago. It's so much better and simpler than S.O.L.I.D. principles that everyone raves about.

Great vid. Your REST API example serves as a sort of materialization of design by contract, which is very OK in my book. It also falls into Allan Kay's "message passing" view which, again, is very OK as far as I'm concerned. As far as the contract and the message is properly documented both sides can go on their merry way and do whatever they have to do on their side. And you can extend it without breaking it by simply adding more endpoints (or versions of). And if you think of it as simply a "boundary between components", you can extend the concept to anything. IMHO, this is where "classic OOP" does a great disservice by not saying that separating data from code is a GoodThingTM. FlowerData is all you can know about Flower. Flower receives FlowerData it can operate on (state). But both are distinct entities. DTO's are an "ashamed acknowledgement" of the fact, as all data can exist without behavior but not the other way around.

With innate motivation to build ood softwae, why is so much software pure garbage?

Can we get the full episodes on RU-vid? Having RU-vid premium and not having full podcast is a bit sad 😔

FREE 'How To Evolve Your Software Architecture' Guide: How to work in ways that keep stuff easy to change which gives you the freedom to make mistakes and experiment and how to work in small steps that allow you to determine their fit for your present understanding of the problem... continuously. All explained in this FREE compact guide. Download HERE ➡ www.subscribepage.com/evolve-your-architecture

I agree with some of his points but not sure why he would find the term accountable so offensive. Surely accountability is just about ensuring that everyone within the team is pulling their weight and working in alignment with the rest of the team? You can have a great team but if you have just one person who isn't accountable, doesn't really care or is often MIA then that will affect the whole team.

You simply cannot measure developer productivity by the number of lines of code written (aka. SLOC, which stands for Source Lines of Code). This metric results in developers gaming the system by writing inefficient code just to inflate their metrics. In the worst case, developers will duplicate procedures and introduce unique bugs into various copies of the code. I once inherited a code base written by 32 developers over the course of 3 years. It was a nightmare. The combined work made up the code for two desktop applications and a communications server that ran as a Windows NT service. Neither of the desktop applications had been successfully compiled in more than a year. To top it off, there were no formal design specifications. After noticing a few duplicated procedures which had different parameters and minor differences in the internal code, my next step was to analyze the code base. I discovered that the majority of procedures had been duplicated between 3 and 14 times. While the intent of each procedure was to perform the same function, the procedures had to be compared against each other to determine which one should be retained. Then all of the code referencing the retained procedures had to have the order of parameters aligned (and in some cases created). Of course, there was no standard convention for naming variables or objects. My manager complained after two weeks about my productivity. He was trying to measure me by SLOC while I was converting the code base to an object-oriented design and removing thousands of no longer needed lines of code per day. I will provide an example to explain how this was possible. One procedure contained 8 lines of code which were repeated so many times with only minor changes that it required 66 sheets of paper to print it to hardcopy. This was rewritten as a single function called in a loop to populate a linked list which held the results. This printed on less than a single sheet, but it didn't help the metrics I was being held to. Fortunately, the senior management and customers were very impressed when I delivered new applications featuring modern user interfaces that loaded data into a tree view from a relational database in less than one second (where the last version that would compile took more than 80 seconds) and a communications server that no longer thread locked after 255 calls. Over the next two months I added the complete backlog of features requested by customers. I measure developer productivity by the number of elements that users can see, the features in the business logic layer and data access layer that they can't, and by customer satisfaction. If the product doesn't meet customer expectations, then nothing else matters.

Fantastic video! Thanks for covering this Dave. Observability is so important and I've seen the benefits of this in production - before and after.

Preach!! 🙏

Great video !

I have to disagree mightily here.. Engineers have a thorough understanding of their area of knowledge from first principles and are primarily designers. Craftsmen have experience and a visceral feeling for their chosen medium and are primarily makers. Both are creative and innovative.. As a wise man once told me, anyone can understand how to lay bricks, few can lay them fast enough to make a living

What we do is programming. That is a profession on its own and it is around since decades. We are not engineers, we are not craftsmen, as we are not salespersons and we are not artists. We do programming aka software development, and usually for a living. Software development comes with its own challenges, while it can involve several skills and activities, which are also helpful in other professions: Creativity, planning, experimenting, measuring, reasoning, testing, communication (between humans) and so on. These are human skills and activities, not attributes of a specific profession. This should not be confused. A rigid view of the world does not reflect its very nature and not our own. So we usually do programming for a living and that is all there is. The hardware which we are programming is completely deterministic. We make sure by excluding randomness with checksums. Measurement and reality checks are deeply integrated into the core of our hardware. The basic building blocks of our profession are very obvious, there is no room and no need for philosophical controversy because of the fundamental principles of what we do for a living. We are not philosophers. So of course we have to build a scientific approach and reality checks into what we create on top ("engineering") when we are interested in results, by thinking and acting in a goal-oriented way. To deny that is just obviously careless. Of course it helps to strive for software to be "well-crafted". What that means may depend on the particular goal, while a well-structured piece of software seems to be more helpful than a chaotic approach. This is just obvious and not a contradiction at all. The universe will have evaporated into nothingness some day, going from order to entropy and beyond. Order is what is needed to resist that a little longer. That insight can and should be applied to software, too. Everyone can establish or become a member of an organization of professionals in particular field. That is a good thing. Call it a "guild", why not. Other professions have that as well. Just do not impose a certain definition upon others by excluding a scientific view of the world. Complete your personal view of the world and go beyond an over-simplified claim, which may even be a good one but not enough by itself. And there is always change. We do not need prejudice against an objective aka scientific view of the world. That is just from the past.

What ever happened to system testing?

Both people in the video are completely wrong. Software IS art not engineering. Here’s the proof. Ask 5 structural engineers to engineer a bridge and you get the same more or less bridge in terms of load, materials, tolerances, etc. Because there are maths involved based on physics and the limits of raw and engineered materials. Ask 5 software “engineers” to write a program and you will have completely different programs and hence interpretations of the requirements. Real engineers aren’t creative they have to adhere to limits of physics for both safety and functionality. When a civil engineer designs something that won’t work because of the limits of physics, they don’t just invent a new molecule or bend the laws of physics they must conform. When a software engineer can’t express what they want in a language they just invent a new one so they can. Perl, node.js, Java, Haskell, LIsP, and dozens of other languages are testimony to the art of software and not the engineering.

What are your thoughts on backlog refinement? Need the whole dev team to have a meeting every Tuesday / Thursday to groom the backlog?

I'd be curious to hear what you think of the book "Software Craftsmanship: A New Imperative" by Pete McBreen and Mike Hendrickson (forward by Dave Thomas). I like their approach to guiding one's own personal development as a programmer, and his notion that educating new programmers should look more like apprenticeship than credentialing, but that could be my own biases as a self-taught programmer showing through. I don't think craftsmanship and engineering are mutually exclusive but rather complementary. Anyway, thanks for the interesting conversation.

Micro-services are not a new idea. UNIX was built around micro-services, only back then they were called processes. So if we want to have a truly useful micro-service architecture, we can learn a lot by looking at the features that the UNIX architecture provided. UNIX offers solutions for: * Configuration of services * Starting and Stopping services in a pre-defined order * Interactively monitoring, starting and stopping services. * Interactively monitoring the input and output to services. * Logging. * Setting a unified Time for the services. * Offering a unified method for reading and writing data, which the user can (re)direct, store and replay as he/she pleases. This is very useful during testing and trouble-shooting. * Methods for authentication & authorization. As it stands, UNIX is locked into the single "computer" paradigm. I wonder why people aren't more interested in e.g. Plan9, which elevates the UNIX principles into a Cloud operating system.

I think the tension between craft and (aspirationally) engineering for software is found even in other media. I remember the cartoons that came with the Metrowerks CodeWarrior products in the 1990s. CodeWarrior (IDE, compilers, etc.) had these cartoons of a factory worker - manually creating giant CDs by hand. Metrowerks was so small I wonder if one of their developers (and making dev tools no less) was involved. I do know there was an open secret that the character was named "Arnie", after the movie star everyone knows about.

Interesting perspective! I would say the craftsmanship manifesto is more informative about what that movement was about, and maybe the name wasn't the best.

I have met software engineers, because I worked in aerospace, but 99% of those who call them selves such are just stealing valor. Software engineers working under a licensed professional engineer with liability insurance to sign off on the systems design and architecture, sure, you pass the gate and are engineers. If you don't know what licensed means or why liability insurance is involved, you are not an engineer.