The problem with Agile is that directors insist on applying waterfall on top of Agile. They achieved the feat of continuing to use Waterfall on top of Agile only to then say a bunch of nonsense like 'Agil doesn't work' where the truth is they want to keep their processes obsolete by adding bureaucracy and inefficiency to the pipeline in order to satisfy some fancy certification
Agreed, most seem to think that agile is about project management, predictability & control. The agile principles around engineering excellence are nowhere to be seen. I personally think scrum is the root cause of this, let’s just rename it small waterfall and be done with it.
this is only true, if the team pick the parts of agile they need, when it come from the top, you end up in 80% meeting 10% planing and 5% working, and 5% who knows.
we are many devs around the world that see there is big problems with all the things we uses, from planning to how to put code together(OOP is dead, it just don't know it) to how to lead, but the most of this, i have be doing for years, customer value is not a new thing, but it is not define that well. also FP and OOP is both wrong, they are colour of the people that define them, too much Math in FP and naming that don't work for many. and OOP is design for making diagram and not code.
TL;DR Thank you for your content You're one of the few tech explainers I really respect when it comes to product development. Your videos are like a breath of fresh air in my stale work life. I love how you break down complex topics with a tech-savvy approach that's still accessible. You always hit the nail on the head and force me to question things I thought I knew. This video comes with perfect timing where I literally had my RTE explain to me that the only important metric is if the code works and I argued to him that this was not a sufficient metric So yeah, that a superb timing. Your work is making a real difference for folks like me in the trenches. Can't wait to see what you cook up next! 😁
I feel like this is very close to, if not exactly, what the Lean Startup methodology is about. I recently started to employ this and am already seeing that my software is not providing enough value as few users are returning and the engagement time is very low. I appreciate everything you put up, keep it up!😊
The way I see agile is that big rewrites or improvements can go very very wrong. Not rarely we spent months or even years changing significant chunks of software just to throw all that work in the bin. Happened numerous times. One of my favorite software "aphorisms" is from my old boss, "bad code that sort-of works is better than perfect code that doesn't exist" which is a very "you don't say" thing to utter and yet we forget it all the time. So keeping software working is a way to prevent big code changes. And if you want to do big code changes, you need to find a way to do it in smaller iterations.
I think you've combined several domains into one umbrella which is confusing when applied to the process of software development.The argument over working software vs customer value does not always make sense from a developers perspective since customer value is rarely managed by a developer. There is of course situations where any combination of design, product management and development can be spread across a team but on the whole developers can focus on working software since it's in their domain and what get's made is not something developers often own.
I see where you’re coming from. But here’s the way I’m thinking that we perhaps should think about it: Instead of training soldiers that are capable of following orders (ie delivering software) we should train soldiers that are capable of thinking for themselves (ie delivering value). See what I mean? If that isn’t practically applicable then it seems to me that we should make it so. No? Do tell me what you think and where you think I’m wrong. Either way thank you very much for watching and for sharing your thoughts. 😊🙏
@@ChristopherOkhravi Managing a product, e.g. speaking to customers, collecting feedback, creating requirements etc. can be a full time job so organizing around domain skills is mainly a bandwidth issue and probably a desire/ skill issue. I do think bespoke agile is better than waterfall but I'm still searching for an even better solution. I do see requirement definitions as a big area for improvement, which ties into what is made but so far I don't have a great approach that would fit into a framework. btw - waterfall has such as bad reputation but there's times when its a much better fit than agile.
@@ChristopherOkhraviconflicts will inevitably arise as soon as the developer notices that the best value for a customer would be to use the product of a competitor.
@@ChristopherOkhravi 100% if all devs could think for themselves, the world would be a better places, i meet a lot of C# devs(we only train c#/ts in Denmark) that check in at 8 and go home at 16 and never learn any thing and need the tasks cut out in small .... you know .. i am a little colour here...
They probably say working software is the measure of progress because agile is looking at software development and not on business development. However applying agile from business development down to software development makes of course far more sense. The whole startup should work on same principles. Anyway this is a great lesson.
Hi Christopher. Not sure I get your point... A software that work does mean more than end-user value which is one parameter... Software Quality is the right balance between 3 parameters: end-user value, and business risks and costs of building and maintaining this value. Also, end-user might not even be a customer but a business employee for example. By making customer value the main driver parameter, then we eventually deliver costly, risky, bad quality software.
Thank you very much for sharing your perspective. Much appreciated. 😊🙏 Could you please expand on how you deduce that we will deliver costly, risky, and bad quality software by keeping the customer in focus? I’m not really following you here 😊
@@ChristopherOkhravi sure. Let's take one simple exemple. Scalability and maintainability. Either your application is a monolith or is a micro service, the end user does not care, it's a black box for him, but not for the business that have to build and maintain (operate) the value to the end user. That applies to any operational system quality attributes. You can find a list of those on Wikipedia.
@@ChristopherOkhravi To demonstrate that customer value does not primarily concern business... What primarily concerns business is business. A software "works" primarily for business... Say a community of users of some software massively request business for a new awesome feature that would have lot of value for them... The business will study cost and risks this feature implies by building and maintaining it... Depending on that, eventually, business will never deliver this value to their customers. This happens all the time. Risks and costs that this feature represents would decrease operational quality of the software for the business operating it. There are 2 types of system quality attributes. Functional and operational. By quality, I assume you mean exclusively functional quality.
@@clementcazaud8040I partially agree with you, and here are the points where I disagree: While it's true that businesses must consider costs and risks, end-user value should not be downplayed as a secondary factor. In many cases, delivering high end-user value drives business success, as it leads to customer satisfaction, loyalty, and ultimately revenue. Therefore, while not the sole driver, end-user value is often critical to a software's success and should be a significant consideration. The distinction between functional and operational quality is important, but your idea seems to imply that focusing on functional quality (end-user value) can degrade operational quality (business risks and costs). In reality, high functional quality often leads to better operational outcomes. For example, well-designed software that meets end-user needs efficiently can reduce support costs, improve system stability, and enhance overall business operations. Dismissing end-user demands too readily can lead to a disconnect between the business and its customers. If a business consistently ignores features that users find valuable, it risks losing those users to competitors who are more responsive to their needs. While cost and risk are valid concerns, they need to be weighed carefully against the potential benefits of satisfying user demands.
@@codewithmert hi, we do not disagree foundamentally. The end goal of software are its functions to its end users. Without these functions, there is no sense in software. However, if we take things in order, we always evaluate costs and risks of a function before delivering or not this function. It really all lays down to the formula I mentioned: software quality = balance(value, costs, risks). Therefore, in reality, we can't say that end user value drives the decisions. In other words, in our world, what matters is the return on investment, not just value to the customer. Beware that functional quality are Not functions of the software... We sometime call them non functional requirements... Things like accessibility, privacy, internationalisation, etc, cf. The list on Wikipedia. Functions are the "what", quality is the "how".
A very thought provoking piece, thanks for this. Agree totally on driving value to the customer. It's something I have a hard time getting my management to focus on.
Really funny because this comes just while we encounter various performance problems, and I just responded to it "Won't fix this. This is not the right way to handle data. Fixing this kind of performance problem would require huge rework and improvements of our current architecture." Because sometimes forbidding a use-case while advising another is smarter than supporting too many use cases. I wonder where you work(ed) and what is your experience because I think you really get the big picture.
How not to love this beautiful, thoughtful and enthusiastic moustache? Great video! ❤
29 дней назад
Hi, Christopher! In terms of Agile Manifesto being Software Development Manifesto, working software is the correct measure of value, as it is being a part of the correct domain. Customer value on the other hand can be measure of progress for the product or service that as you said it yourself (4:35) may be outside of the domain of software development.
Coming from a consultancy, it seems like often it comes down to the money spent and software delivered on time instead of whether it's provides the proposed value unfortunately
For consulting, I would expect this to depend on the contract. If ghe contract says "deliver this software" then this is the goal.If the contract says " solve that problem" then that is the goal.
Agile is about shipping Software with customer value early rather than late. The first principle "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software" implies that "working software" fullfills customer value.
From refer to the documentation, and look up the specifications, we came to "figure it out trough the code" which is fine for small projects, but when that project get as large as 7k classes... Guidelines are important IMO, but everything you stated pretty much sums it up. I would be impressed if a "project manager" actually watched your videos and had some idea how to guide the project and not wing it...
"directly" is the key word here. One should not focus on "directly", but at the near future. The exact timeframe differs per use case and depends on e.g. the runway of a startup or market trends or competition etc. So, yes, sometimes postponing refactoring (or taking on other tech debt) is the right thing to do: if the choice is between being out of business next week (eg missing a crucial deal) and we'll factored code, the Choice is obvious. Also, well factored code that no one uses, is worthless. But refactoring means you can keep delivering updates, keep hitting deadlines and keep improving customer value today and in a year. So when you are reasonable sure you and your software is around in a year, refactoring today is critical. Because otherwise you can no longer deliver value in the future.
Actually i have this issue with documents, i work for governmental agency with a lot of requirements and business goals with a need to quick development to achieve it's programs. most of my time spent in development a little tiny of my time document these operations, this approach brings a guilte feeling and makes me always wonder is that good enough? or i need more docments for lanched projects? so i decide to declare a "Minimal Document Approahc" for each project based on it's complixty degree. 1:40
Aren’t you just restating the first principle with different words “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”
"No premature abstraction" and "Never leave a mess" to me sound so much on the opposite sides that I'd very much like to know what abstractions you think should be avoided (prematurely)? From my experience the problem is not finding the right abstractions, or taking too much time to find them, and often still finding the wrong ones - lack of experience (or skill). For instance: having a very specific types of content (later discovered that it was just that - content), and introducing new similar types of such content while in many places it should've been just "content" - in some models the type mattered, but in most of them it didn't, not utilizing this resulted in creating unnecessary types and duplication. Other example: getting requirement for a specific rule for a water heater, on the topic of for how long it can be turned off before it becomes contaminated with bacteria - luckily (or rather skillfully) we discovered that at the heart of that rule is simply up-time monitoring - something that later can be reused.
I'd say the first is not premature abstraction. Premature abstraction would have been if you had only one content type but already created an abstraction based on that you might later on need another content type (only to find out as soon as you actually get the second content type, that you abstracted the wrong properties). The second example, I wouldn't consider abstraction at all, but rather understanding the problem. Which of course is always helpful.
Agile is just micromanagement wrapped around enough marketing slogans/quotes/fancy idealizations to be able to sell books and courses. You need design to make good software, and good design is part of the value provided to the customer. And documentation is needed for maintenance, which is part of the customer value. I'm tired of people pretending that good design and documentation isn't necessary. It's annoying joining a company and having to deal what others left incomplete and completely undocumented. F%ck agile
Problem with Agile is that it became a "managers job", with managers metrics and numbers and not about software at all. And even if you say customer value first, companies will still push for what make more money for their investors above that. I agree with all points, but maybe its lacking the value of being "easy to change" (maybe even "easy to delete"! for when it's not valuable anymore) Also: some things are more valuable longterm. But we can't be shortsighted and just pursue short gains. Since this depends on the stage of whats being built, I would say something along the lines of: "the longer its running, the longer you have to consider", it's ok for a startup to chase short gains, but the longer it stays there, the more in the future it has to evaluate what is value. So, while short term value of something is bigger, they can chase a long term value it it's seeing like, for as long as the product is already there.
Yes! I saw that ALL the time during planning and grooming. My first question is always, "What is the value to the user", when we are creating user stories. If you can't articulate the value then it's not a story and you need to rethink. There's too much "yes men" (gender neutral "men") mentality and with agile it only makes it more obvious. At least with waterfall you could hide behind milestones, but with agile, since it's designed to be transparent, there is nowhere to "hide" :). That compels people to do work when it's not necessary which just introduces tech debt and more work down the line. Tech debt is costly and dangerous. How many exploits have been taken advantage of because of old crufty code that should have been refactored, but wasn't due to "cost" or "time"? What about value? I think customers would hold value in their software being secure right? That's just one example, but it's prevalent in the industry. In my almost thirty years in this industry I've seen things "change", but really, it's still the same stuff as before. There is no true innovation in software. We just iterate on what is already there, and that, in my opinion, is an avenue for mediocracy. If you want to be mediocre and are satisfied with that, then by all means, keep writing derivative systems, but call them something else just so it seems like it's new.
The arrival of the Internet killed the build quality and stability of software. 30 years ago, every application had only a few updates. Everything often worked fine in the first version. Now you have to wait at least 10 updates before moving to the next version ... You feel like you are constantly driving a malfunctioning car ...
This is a very interesting point that I need to meditate on. I definitely think this is a very important perspective. Thank you for watching and for sharing. 😊🙏
Hehe 😊 I don’t mean to say “value from not working software” but rather “value not from working software but from something else”. See what I mean? 😊 Then again, in the video I’m also arguing that sometimes it is more valuable to move on from something that’s working good enough so that we can focus on the next thing, rather than making the thing we’re currently working on work perfectly. Either way, thank you very much for watching and for commenting 😊
Quite often, you can give "customer value" without a "product" in the form of software. Sometimes, a weekly call solves the problem. Sometimes hiring a specialist solves the problem. Sometimes an excel spreadsheet solves the problem. Sometimes the problem is so small that people don't want to buy or learn new software to solve it. Sometimes just sitting down and removing tasks or roles or jobs solves the problem. We developers often have professional deformation. I do. I've built several software startups, fancy SAAS to solve problems that, when we finally launched, were commonly and successfully solved with sticky notes, or someone doing some extra work and so on. Wasted months of my life and chunks of my savings to learn that lesson.
And this is why the Product people will always be way ahead (and above) the Tech/Engineering people, because this fact is not only clear to them, it is their entire focus. The only reason why Tech/Engineering has representation outside "the factory" is because they control the production. But Christopher, there is one more step further you must go to understand the entire tech industry: Shareholder* value is the primary measure of success. *(Be it VC or the "owners") So, this all begs the question: what are we writing code for?
customer value implies working software to help oposite doesn't have to be true. but you are wrong in your analysis. customers are a type of stakeholders. and value can differ for each of them. also value can be provided incrementally for this to happen working software is a necessity but it means that the value is nit yet on the software. thus it is still about working software.
Agile is like communism, sounds great on paper, but once people start implementing and it becomes hellish and developers burn out, they start saying: "Oh that wasn't real agile"
![[DOKKAN BATTLE] Worldwide Campaign Announcement Video Part 2!](http://i.ytimg.com/vi/JpT5Voak6WA/mqdefault.jpg)
Dude. You just summarised in 15 minutes what I attempt to teach my IT architecture students in a full semester.
Thank you for the very kind words. I'm happy to hear that we seem to be thinking about things in similar ways.
The problem with Agile is that directors insist on applying waterfall on top of Agile. They achieved the feat of continuing to use Waterfall on top of Agile only to then say a bunch of nonsense like 'Agil doesn't work' where the truth is they want to keep their processes obsolete by adding bureaucracy and inefficiency to the pipeline in order to satisfy some fancy certification
Lol, agile with monthly milestone deliverables!
Agreed, most seem to think that agile is about project management, predictability & control. The agile principles around engineering excellence are nowhere to be seen. I personally think scrum is the root cause of this, let’s just rename it small waterfall and be done with it.
this is only true, if the team pick the parts of agile they need, when it come from the top, you end up in 80% meeting 10% planing and 5% working, and 5% who knows.
You are onto something. I do like and agree with such a flexible view
👊😊
we are many devs around the world that see there is big problems with all the things we uses, from planning to how to put code together(OOP is dead, it just don't know it) to how to lead, but the most of this, i have be doing for years, customer value is not a new thing, but it is not define that well.
also FP and OOP is both wrong, they are colour of the people that define them, too much Math in FP and naming that don't work for many.
and OOP is design for making diagram and not code.
Agile is the way to get customer's money to move into software development company's pockets faster instead of waiting for the project to complete.
😆
TL;DR Thank you for your content
You're one of the few tech explainers I really respect when it comes to product development.
Your videos are like a breath of fresh air in my stale work life.
I love how you break down complex topics with a tech-savvy approach that's still accessible.
You always hit the nail on the head and force me to question things I thought I knew.
This video comes with perfect timing where I literally had my RTE explain to me that the only important metric is if the code works and I argued to him that this was not a sufficient metric
So yeah, that a superb timing.
Your work is making a real difference for folks like me in the trenches.
Can't wait to see what you cook up next! 😁
I feel like this is very close to, if not exactly, what the Lean Startup methodology is about.
I recently started to employ this and am already seeing that my software is not providing enough value as few users are returning and the engagement time is very low.
I appreciate everything you put up, keep it up!😊
The way I see agile is that big rewrites or improvements can go very very wrong. Not rarely we spent months or even years changing significant chunks of software just to throw all that work in the bin. Happened numerous times. One of my favorite software "aphorisms" is from my old boss, "bad code that sort-of works is better than perfect code that doesn't exist" which is a very "you don't say" thing to utter and yet we forget it all the time. So keeping software working is a way to prevent big code changes. And if you want to do big code changes, you need to find a way to do it in smaller iterations.
In my experience the most inexperienced devs want the most rewrites. It usually come down to lack of comprehension when reading other peoples code.
I think you've combined several domains into one umbrella which is confusing when applied to the process of software development.The argument over working software vs customer value does not always make sense from a developers perspective since customer value is rarely managed by a developer. There is of course situations where any combination of design, product management and development can be spread across a team but on the whole developers can focus on working software since it's in their domain and what get's made is not something developers often own.
I see where you’re coming from. But here’s the way I’m thinking that we perhaps should think about it: Instead of training soldiers that are capable of following orders (ie delivering software) we should train soldiers that are capable of thinking for themselves (ie delivering value). See what I mean? If that isn’t practically applicable then it seems to me that we should make it so. No? Do tell me what you think and where you think I’m wrong.
Either way thank you very much for watching and for sharing your thoughts. 😊🙏
@@ChristopherOkhravi Managing a product, e.g. speaking to customers, collecting feedback, creating requirements etc. can be a full time job so organizing around domain skills is mainly a bandwidth issue and probably a desire/ skill issue.
I do think bespoke agile is better than waterfall but I'm still searching for an even better solution. I do see requirement definitions as a big area for improvement, which ties into what is made but so far I don't have a great approach that would fit into a framework.
btw - waterfall has such as bad reputation but there's times when its a much better fit than agile.
@@ChristopherOkhravi In a lot of companies that's for the BO/PO/Director to decide; devs are there for bandwidth not unsolicited advice.
@@ChristopherOkhraviconflicts will inevitably arise as soon as the developer notices that the best value for a customer would be to use the product of a competitor.
@@ChristopherOkhravi 100% if all devs could think for themselves, the world would be a better places, i meet a lot of C# devs(we only train c#/ts in Denmark) that check in at 8 and go home at 16 and never learn any thing and need the tasks cut out in small .... you know .. i am a little colour here...
It's truly eyes opening Christopher! I am joining your value driven movement :)
They probably say working software is the measure of progress because agile is looking at software development and not on business development.
However applying agile from business development down to software development makes of course far more sense. The whole startup should work on same principles. Anyway this is a great lesson.
Hi Christopher. Not sure I get your point... A software that work does mean more than end-user value which is one parameter... Software Quality is the right balance between 3 parameters: end-user value, and business risks and costs of building and maintaining this value. Also, end-user might not even be a customer but a business employee for example. By making customer value the main driver parameter, then we eventually deliver costly, risky, bad quality software.
Thank you very much for sharing your perspective. Much appreciated. 😊🙏 Could you please expand on how you deduce that we will deliver costly, risky, and bad quality software by keeping the customer in focus? I’m not really following you here 😊
@@ChristopherOkhravi sure. Let's take one simple exemple. Scalability and maintainability. Either your application is a monolith or is a micro service, the end user does not care, it's a black box for him, but not for the business that have to build and maintain (operate) the value to the end user. That applies to any operational system quality attributes. You can find a list of those on Wikipedia.
@@ChristopherOkhravi To demonstrate that customer value does not primarily concern business... What primarily concerns business is business. A software "works" primarily for business...
Say a community of users of some software massively request business for a new awesome feature that would have lot of value for them...
The business will study cost and risks this feature implies by building and maintaining it... Depending on that, eventually, business will never deliver this value to their customers. This happens all the time.
Risks and costs that this feature represents would decrease operational quality of the software for the business operating it.
There are 2 types of system quality attributes. Functional and operational. By quality, I assume you mean exclusively functional quality.
@@clementcazaud8040I partially agree with you, and here are the points where I disagree:
While it's true that businesses must consider costs and risks, end-user value should not be downplayed as a secondary factor. In many cases, delivering high end-user value drives business success, as it leads to customer satisfaction, loyalty, and ultimately revenue. Therefore, while not the sole driver, end-user value is often critical to a software's success and should be a significant consideration.
The distinction between functional and operational quality is important, but your idea seems to imply that focusing on functional quality (end-user value) can degrade operational quality (business risks and costs). In reality, high functional quality often leads to better operational outcomes. For example, well-designed software that meets end-user needs efficiently can reduce support costs, improve system stability, and enhance overall business operations.
Dismissing end-user demands too readily can lead to a disconnect between the business and its customers. If a business consistently ignores features that users find valuable, it risks losing those users to competitors who are more responsive to their needs. While cost and risk are valid concerns, they need to be weighed carefully against the potential benefits of satisfying user demands.
@@codewithmert hi, we do not disagree foundamentally. The end goal of software are its functions to its end users. Without these functions, there is no sense in software. However, if we take things in order, we always evaluate costs and risks of a function before delivering or not this function. It really all lays down to the formula I mentioned: software quality = balance(value, costs, risks). Therefore, in reality, we can't say that end user value drives the decisions. In other words, in our world, what matters is the return on investment, not just value to the customer.
Beware that functional quality are Not functions of the software... We sometime call them non functional requirements... Things like accessibility, privacy, internationalisation, etc, cf. The list on Wikipedia.
Functions are the "what", quality is the "how".
A very thought provoking piece, thanks for this. Agree totally on driving value to the customer. It's something I have a hard time getting my management to focus on.
Software that works is software that works for the problem the customer has.
Really funny because this comes just while we encounter various performance problems, and I just responded to it "Won't fix this. This is not the right way to handle data. Fixing this kind of performance problem would require huge rework and improvements of our current architecture."
Because sometimes forbidding a use-case while advising another is smarter than supporting too many use cases.
I wonder where you work(ed) and what is your experience because I think you really get the big picture.
How not to love this beautiful, thoughtful and enthusiastic moustache? Great video! ❤
Hi, Christopher! In terms of Agile Manifesto being Software Development Manifesto, working software is the correct measure of value, as it is being a part of the correct domain. Customer value on the other hand can be measure of progress for the product or service that as you said it yourself (4:35) may be outside of the domain of software development.
Coming from a consultancy, it seems like often it comes down to the money spent and software delivered on time instead of whether it's provides the proposed value unfortunately
For consulting, I would expect this to depend on the contract. If ghe contract says "deliver this software" then this is the goal.If the contract says " solve that problem" then that is the goal.
Agile is about shipping Software with customer value early rather than late. The first principle "Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software" implies that "working software" fullfills customer value.
Great job mate. You are on to something there. Keep at it!!! Cheers
From refer to the documentation, and look up the specifications, we came to "figure it out trough the code" which is fine for small projects, but when that project get as large as 7k classes... Guidelines are important IMO, but everything you stated pretty much sums it up. I would be impressed if a "project manager" actually watched your videos and had some idea how to guide the project and not wing it...
Refactoring doesn't directly add value for the customer, so... never refactor?
"directly" is the key word here.
One should not focus on "directly", but at the near future. The exact timeframe differs per use case and depends on e.g. the runway of a startup or market trends or competition etc.
So, yes, sometimes postponing refactoring (or taking on other tech debt) is the right thing to do: if the choice is between being out of business next week (eg missing a crucial deal) and we'll factored code, the Choice is obvious. Also, well factored code that no one uses, is worthless.
But refactoring means you can keep delivering updates, keep hitting deadlines and keep improving customer value today and in a year.
So when you are reasonable sure you and your software is around in a year, refactoring today is critical. Because otherwise you can no longer deliver value in the future.
What do you consider to be the difference between inheritance and subtype polymorphism?
You are a legend, thanks for sharing!
Actually i have this issue with documents, i work for governmental agency with a lot of requirements and business goals with a need to quick development to achieve it's programs. most of my time spent in development a little tiny of my time document these operations, this approach brings a guilte feeling and makes me always wonder is that good enough? or i need more docments for lanched projects? so i decide to declare a "Minimal Document Approahc" for each project based on it's complixty degree. 1:40
If that doesn't work with the software development, he could also become a magician. He's got that vibe!
Aren’t you just restating the first principle with different words “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”
100%
Please make a video about multi module SOA in java and how to achieve interaction between modules in the system
"No premature abstraction" and "Never leave a mess" to me sound so much on the opposite sides that I'd very much like to know what abstractions you think should be avoided (prematurely)?
From my experience the problem is not finding the right abstractions, or taking too much time to find them, and often still finding the wrong ones - lack of experience (or skill).
For instance: having a very specific types of content (later discovered that it was just that - content), and introducing new similar types of such content while in many places it should've been just "content" - in some models the type mattered, but in most of them it didn't, not utilizing this resulted in creating unnecessary types and duplication.
Other example: getting requirement for a specific rule for a water heater, on the topic of for how long it can be turned off before it becomes contaminated with bacteria - luckily (or rather skillfully) we discovered that at the heart of that rule is simply up-time monitoring - something that later can be reused.
I'd say the first is not premature abstraction. Premature abstraction would have been if you had only one content type but already created an abstraction based on that you might later on need another content type (only to find out as soon as you actually get the second content type, that you abstracted the wrong properties).
The second example, I wouldn't consider abstraction at all, but rather understanding the problem. Which of course is always helpful.
Great insights here.
Gold principles! the seven 'Never'!
Hey Christopher, I want to buy your book but I don't see a way to pay with google pay - can you arrange that?
God damn, your energy and explanation are always amazing!
Excellent video, as usual. Thank you!
I loved your analysis, it's inspiring!
Agile is just micromanagement wrapped around enough marketing slogans/quotes/fancy idealizations to be able to sell books and courses. You need design to make good software, and good design is part of the value provided to the customer. And documentation is needed for maintenance, which is part of the customer value. I'm tired of people pretending that good design and documentation isn't necessary. It's annoying joining a company and having to deal what others left incomplete and completely undocumented. F%ck agile
Documentation is important (and too often neglected), but it should be developed alongside the code.
Love this guy ❤
Problem with Agile is that it became a "managers job", with managers metrics and numbers and not about software at all.
And even if you say customer value first, companies will still push for what make more money for their investors above that.
I agree with all points, but maybe its lacking the value of being "easy to change" (maybe even "easy to delete"! for when it's not valuable anymore)
Also: some things are more valuable longterm. But we can't be shortsighted and just pursue short gains. Since this depends on the stage of whats being built, I would say something along the lines of: "the longer its running, the longer you have to consider", it's ok for a startup to chase short gains, but the longer it stays there, the more in the future it has to evaluate what is value. So, while short term value of something is bigger, they can chase a long term value it it's seeing like, for as long as the product is already there.
Yes! I saw that ALL the time during planning and grooming. My first question is always, "What is the value to the user", when we are creating user stories. If you can't articulate the value then it's not a story and you need to rethink. There's too much "yes men" (gender neutral "men") mentality and with agile it only makes it more obvious. At least with waterfall you could hide behind milestones, but with agile, since it's designed to be transparent, there is nowhere to "hide" :). That compels people to do work when it's not necessary which just introduces tech debt and more work down the line. Tech debt is costly and dangerous. How many exploits have been taken advantage of because of old crufty code that should have been refactored, but wasn't due to "cost" or "time"? What about value? I think customers would hold value in their software being secure right? That's just one example, but it's prevalent in the industry. In my almost thirty years in this industry I've seen things "change", but really, it's still the same stuff as before. There is no true innovation in software. We just iterate on what is already there, and that, in my opinion, is an avenue for mediocracy. If you want to be mediocre and are satisfied with that, then by all means, keep writing derivative systems, but call them something else just so it seems like it's new.
The arrival of the Internet killed the build quality and stability of software. 30 years ago, every application had only a few updates. Everything often worked fine in the first version. Now you have to wait at least 10 updates before moving to the next version ... You feel like you are constantly driving a malfunctioning car ...
This is a very interesting point that I need to meditate on. I definitely think this is a very important perspective. Thank you for watching and for sharing. 😊🙏
A prior video I called you a nitwit. Or perhaps I was thinking that :D This one is remarkably good. Well done.
Too good to follow 😊
"They are the same picture"...
Seriously what value for client is from not working software ?
Hehe 😊 I don’t mean to say “value from not working software” but rather “value not from working software but from something else”. See what I mean? 😊 Then again, in the video I’m also arguing that sometimes it is more valuable to move on from something that’s working good enough so that we can focus on the next thing, rather than making the thing we’re currently working on work perfectly. Either way, thank you very much for watching and for commenting 😊
but customer value is formed on working product better product brings more customer
Quite often, you can give "customer value" without a "product" in the form of software.
Sometimes, a weekly call solves the problem. Sometimes hiring a specialist solves the problem. Sometimes an excel spreadsheet solves the problem. Sometimes the problem is so small that people don't want to buy or learn new software to solve it. Sometimes just sitting down and removing tasks or roles or jobs solves the problem.
We developers often have professional deformation. I do. I've built several software startups, fancy SAAS to solve problems that, when we finally launched, were commonly and successfully solved with sticky notes, or someone doing some extra work and so on. Wasted months of my life and chunks of my savings to learn that lesson.
Brilliant!!
Mh programmers make the deliverables though. Documents are for the developer not the consumer.
Meanwhile I develop for a stupid project for VisionOS no one is gonna use
My man surfing?
👏👏👏👏
HMMM!! Make Sense
And this is why the Product people will always be way ahead (and above) the Tech/Engineering people, because this fact is not only clear to them, it is their entire focus. The only reason why Tech/Engineering has representation outside "the factory" is because they control the production.
But Christopher, there is one more step further you must go to understand the entire tech industry: Shareholder* value is the primary measure of success. *(Be it VC or the "owners")
So, this all begs the question: what are we writing code for?
customer value implies working software to help oposite doesn't have to be true. but you are wrong in your analysis. customers are a type of stakeholders. and value can differ for each of them. also value can be provided incrementally for this to happen working software is a necessity but it means that the value is nit yet on the software. thus it is still about working software.
Agile is like communism, sounds great on paper, but once people start implementing and it becomes hellish and developers burn out, they start saying: "Oh that wasn't real agile"
Good video, sounds very true!