Preferably if you are waiting on requirements, gather them. Blindly building can be worse than doing nothing. Or use this time to do the refactor that you always wanted
Or build something else for which you already have requirements. It's not like you actually wait and do nothing at all while waiting for some input from the relevant actor. If they really wanted that feature, they would have gotten back to you already. Make sure you remind them though.
I really think this is the best approach Have some not-feature-related tasks on backlog, or proof of concepts you want to test, or refactors... When you have some free time, instead of building stuff that will delay others, require their time for reviews, just to throw away, do those backlog tasks.
Misleading title….it’s don’t wait for *definition*, not requirements. I’ve literally never agreed with Uncle Bob, but this I agree with him on. “If you don’t have an API….then *you* define the API”. Spot on. If it doesn’t matter, it doesn’t matter, and if it does then they’ll sure shout and scream now. And then you know what’s important.
I get the message but the delivery is incorrect. Doing something is not always better than doing nothing Always doing something leads to 100% utilization which is a very inefficient system. Also, the fear of engineers being idle is what leads to feature factories But yes, engineers should learn how to make the requirements as well. When you continue shifting left, you will eventually find yourself co-creating the requirements with product/business/user
Nope. The engineer is about the "how", not the "what"...engineers can certainly suggest the "what", but only suggestions...its about Separation of Concerns, roles, swimlanes...product owners come up with the requirements, not the engineers.
@Mark73 it doesn't align with the reality of software development. A customer has a specific set of requirements. Writing code without knowing those requirements is just about the dumbest fucking advice available. He's suggesting writing any code is better than not having code at all, but that's simply not true. if you write code before you know the requirements you are inevitably getting into Tech debt. Sure he argues that if you create some kind of interface, it doesn't matter, but when are you going to have the time to then replace that back end and rewrite it so that it's not just a bunch of garbage? The answer is never. This is fundamentally bad advice especially in the software industry. If your requirements are customer driven then you wait on the requirements from the customer. Anything else is uter stupidity. There are other things you can work on, not just this one problem no one works at a company where all work halts because there's a single feature you need to develop. The real problem that shows is how many developers get only the what the customer wants to do not the why the customer wants to do it. You need both of those to properly understand the requirements and develop a solution. The reality is customers don't really know the what, but they do know the why. If you know the why you can fix the what that they're describing.
@@Mark73, engineers are about that "how" things get built, not the "what" gets built. The product owners come up with the "what" to build. We stay in our own swimlanes, and we respect Separation of Concerns. The tail does not wag the dog.
You confuse building a product with developers gathering the requirements...what you don't understand is that coders are about the how, not the what. We developers are not mind readers...if the business wants to create a product in speculation, not knowing if customers want it, then its their choice, not the choice of developers.
@@bhbr-xb6po Do you think that the developers are gathering the requirements from the customers? Because they aren't. They're trying to get the requirements from the project manager.
Please do not follow this advice, it's awful. Last thing we want is devs wasting their time. You don't have the requirements? Push back onto the consultant or customer. Go work on something else. You don't need to sit in your hands, but blindly creating something is a recipe for disaster.
Is your company paid to run that no requierements cycle? * Yes: do it, it will allow the customer to come up with the requierements. Do NOT abstract away too much, it will create a more complex code (so to deal with that extra complexity, you need to renegotiate project scope/estimates) * No: work on another feature. If there is no other properly defined feature, you need to renegotiate project schedulle. The idea is cool, considering puntual mass particles in a vacuum
Actually, the idea of working on a project without a requirement is never "cool". If you are a coder, its never your place to provide the product requirements...that's the job of the product owner, and the customers.
Software can be anything, but a product is a vision from a team together. Failing to shave requirements means failing to communicate and work together for the product benefit. Don’t build what you don’t own.
This advice is 100% wrong. After 46 years of coding, I know for a fact that this advice is wrong. I've seen this thinking crash and burn too many budgets, and waste far too much time. So now we are mind readers? The problem is not building too late, but communication...if the requirements are not defined yet, it is far better to wait for them. Its not on you! You are not about the what to build...you are about the how to build...imagine building a house before you know the layout...
You say: “it is far better to wait for them”. What do you do in the meantime? If you have a concept of an idea of a requirement it should be enough to start building something
@@akoshkin1, while waiting, you never just sit around. Instead, work on something else, build tools, refactor code, learn the framework. But, never start working on a project whose requirements are still outstanding. A "concept of an idea" is never enough. Its a trap!
Carefull! This mentality can become very easy a recipe for desaster and a huge waste of time and effort! And no, even if you learnd somsthing, this usually does not justify it. Especially when software developers go unhinged and create abstraction, interfaces and so on. Most of the time, they build a expensive pipe dream that is way more a liability than an asset! The term software crisis stands for more than 6 decades and still going strong . . . get your shit together soft boys! (a hardware guy is speaking here 😁)
Wrong! Your video applies to websites and some startup companies but not the global ones. REQs are A&O for large organizations and when the concepts are complicated guess what, you need those extra pair of eyes to ensure objectivity in the quality of the product!
Preferably if you are waiting on requirements, gather them. Blindly building can be worse than doing nothing.
Or use this time to do the refactor that you always wanted
Or build something else for which you already have requirements.
It's not like you actually wait and do nothing at all while waiting for some input from the relevant actor.
If they really wanted that feature, they would have gotten back to you already.
Make sure you remind them though.
I really think this is the best approach
Have some not-feature-related tasks on backlog, or proof of concepts you want to test, or refactors... When you have some free time, instead of building stuff that will delay others, require their time for reviews, just to throw away, do those backlog tasks.
Refactor is always a good choice
Or some CI work even, so that you can deliver faster when those requirements are eventually clarified.
@@nikarmotte very good point, you'll probably never regret improving ci/cd. Or do some work on observability, alarms, graphs
Misleading title….it’s don’t wait for *definition*, not requirements. I’ve literally never agreed with Uncle Bob, but this I agree with him on. “If you don’t have an API….then *you* define the API”. Spot on. If it doesn’t matter, it doesn’t matter, and if it does then they’ll sure shout and scream now. And then you know what’s important.
I get the message but the delivery is incorrect. Doing something is not always better than doing nothing
Always doing something leads to 100% utilization which is a very inefficient system. Also, the fear of engineers being idle is what leads to feature factories
But yes, engineers should learn how to make the requirements as well. When you continue shifting left, you will eventually find yourself co-creating the requirements with product/business/user
Nope. The engineer is about the "how", not the "what"...engineers can certainly suggest the "what", but only suggestions...its about Separation of Concerns, roles, swimlanes...product owners come up with the requirements, not the engineers.
I would love to sit in at the lecture!
I'd like to get a longer video expanding on this.
ruclips.net/video/YN_A_S0pzz4/видео.html
Why do you want to hear more bad advice?
@mattymattffs please explain why this is bad advice
@Mark73 it doesn't align with the reality of software development. A customer has a specific set of requirements. Writing code without knowing those requirements is just about the dumbest fucking advice available. He's suggesting writing any code is better than not having code at all, but that's simply not true. if you write code before you know the requirements you are inevitably getting into Tech debt. Sure he argues that if you create some kind of interface, it doesn't matter, but when are you going to have the time to then replace that back end and rewrite it so that it's not just a bunch of garbage? The answer is never. This is fundamentally bad advice especially in the software industry. If your requirements are customer driven then you wait on the requirements from the customer. Anything else is uter stupidity. There are other things you can work on, not just this one problem no one works at a company where all work halts because there's a single feature you need to develop.
The real problem that shows is how many developers get only the what the customer wants to do not the why the customer wants to do it. You need both of those to properly understand the requirements and develop a solution. The reality is customers don't really know the what, but they do know the why. If you know the why you can fix the what that they're describing.
@@Mark73, engineers are about that "how" things get built, not the "what" gets built. The product owners come up with the "what" to build. We stay in our own swimlanes, and we respect Separation of Concerns. The tail does not wag the dog.
A great company builds the product its customers never knew they wanted. Instead of what they think the customers think they need.
Thanks for the non insight. You’re mistaking YT comments with LinkedIn
You confuse building a product with developers gathering the requirements...what you don't understand is that coders are about the how, not the what. We developers are not mind readers...if the business wants to create a product in speculation, not knowing if customers want it, then its their choice, not the choice of developers.
@@bhbr-xb6po Do you think that the developers are gathering the requirements from the customers?
Because they aren't. They're trying to get the requirements from the project manager.
Please do not follow this advice, it's awful. Last thing we want is devs wasting their time. You don't have the requirements? Push back onto the consultant or customer. Go work on something else. You don't need to sit in your hands, but blindly creating something is a recipe for disaster.
Mythical Man Month: Be prepared to Throw it Away, because you are going to anyway!
I have learned this very quickly doing freelance Shopify development
Is your company paid to run that no requierements cycle?
* Yes: do it, it will allow the customer to come up with the requierements. Do NOT abstract away too much, it will create a more complex code (so to deal with that extra complexity, you need to renegotiate project scope/estimates)
* No: work on another feature. If there is no other properly defined feature, you need to renegotiate project schedulle.
The idea is cool, considering puntual mass particles in a vacuum
Actually, the idea of working on a project without a requirement is never "cool". If you are a coder, its never your place to provide the product requirements...that's the job of the product owner, and the customers.
Software can be anything, but a product is a vision from a team together.
Failing to shave requirements means failing to communicate and work together for the product benefit.
Don’t build what you don’t own.
This advice is 100% wrong. After 46 years of coding, I know for a fact that this advice is wrong. I've seen this thinking crash and burn too many budgets, and waste far too much time. So now we are mind readers? The problem is not building too late, but communication...if the requirements are not defined yet, it is far better to wait for them. Its not on you! You are not about the what to build...you are about the how to build...imagine building a house before you know the layout...
100%. This is terrible advice. It makes it sound like he's never hung around to actually support a project.
You say: “it is far better to wait for them”. What do you do in the meantime?
If you have a concept of an idea of a requirement it should be enough to start building something
@akoshkin1 what kind of question is that? You work on something else
@@akoshkin1, while waiting, you never just sit around. Instead, work on something else, build tools, refactor code, learn the framework. But, never start working on a project whose requirements are still outstanding. A "concept of an idea" is never enough. Its a trap!
Carefull! This mentality can become very easy a recipe for desaster and a huge waste of time and effort! And no, even if you learnd somsthing, this usually does not justify it. Especially when software developers go unhinged and create abstraction, interfaces and so on. Most of the time, they build a expensive pipe dream that is way more a liability than an asset! The term software crisis stands for more than 6 decades and still going strong . . . get your shit together soft boys! (a hardware guy is speaking here 😁)
Wait. Does this mean that SCRAM is a bad idea?😂
what if after working and they say that a feature is not required we are dropping and looking for new feature😢
Except when Product yells at you if you depart from the ticket in the least. Ask me how I know...
Wondering how this makes dev tools simpler
Most software engineers eventually learn to not listen to Uncle Bob
Why? >.>
@@MrEliteXXL a whole lot of assertions with very little evidence
Wrong! Your video applies to websites and some startup companies but not the global ones. REQs are A&O for large organizations and when the concepts are complicated guess what, you need those extra pair of eyes to ensure objectivity in the quality of the product!
Balderdash -- bull dubg
The devil finds work for idle hands.
😂
This is more inspiring than any 'motivational talk'
Except, that its wrong advice...
boss makes a dollar, i make a dime.
thats why i browse reddit on company time