Go Full Circle | Code Walks 059

Postmortem. Admitting and learning from our mistakes is, imho, incredibly important if we are to become better programmers. In this postmortem video I share and dissect my most recent massive failure.
Knowing about Agile, Lean, MVPs, Incremental Development, and so on, is one thing. Actually successfully executing upon it is a whole different beast.
I try to take full responsibility for my actions, include my mistakes, which is why I'm making this video. What's the reason for failing if not to learn.
What do you think? Was I simply stupid? Do you have any similar experiences? Share your thoughts.
MORE VIDEOS
► AGILE MANIFESTO (playlist)
• Agile Manifesto Values
► Minimum Viable Products (MVP) (video)
• Minimum Viable Product...
► Patreon
patreon.christo...

[@supratimdatta7848]

Hey christopher, I agree, on your point.We have faced this issue as well working with agile,especially if the client is not very clear of their own requirement vis a vis what is technologically possible within the agile time frame , and unable to understand what was being delivered.Only if we keep displaying a minimal viable product can they understand what is the current state of progress and they can actually provide solutions/tweak requirements which we as developers cannot.

[@crazyfox55]

I agree, a helpful interpretation is the manifestation of an idea is the deliverable. The problem coders run into is requirement documents seem like the manifestation of an idea, but from a client it still just an idea. Its similar to receiving a description to make a car and delivering to the client another "more specific" description to make a car. Thanks for the videos, always thought provoking.

[@TheMinino123]

This is really interesting. I think we need to focus on having a balance in documentation and actual deliverables. And having a pretty neat, clear, consistent, and even fun documentation (using diagrams as much as possible in order to have it readable) would be really productive in the software development ^_^

[@SunggukLim]

Watched again to remind to myself again.

[@theguy9067]

I think the idea of not documenting things is ridiculous. Word of mouth has no record and people have bad memory. You develop something and a few months later no one can remember what was actually required. When a new requirement/ bug comes up it should be documented somewhere in my opinion. Also, some people including myself find it easier to understand requirements when it's in written form.

[@pinkponyofprey1965]

Interesting however slightly abstract if you're not already in with both feet developing away. But interesting.

[@ChristopherOkhravi]

+PinkPonyOfPrey Super good feedback. Thanks. Will try to make future videos more inclusive! :) Thanks for watching.

[@chrisjust7445]

But you do need some requirements, otherwise how will you know what you're building or when you're done? QA needs requirements to know what and how to test. The thing is to document requirements for just the small piece of the puzzle you're building at that time, not for the entire product. Once you finish & demo one piece of the product, you can start mapping out requirements for the next piece...

[@elliott8175]

I think he meant that you should document enough requirements to have the skeleton of the complete program. So you'd need good intuition as to what requirements might affect the overall structure of your code.

[@chrisjust7445]

@@elliott8175 Then you're just assuming the requirements; and you know what happens when you AssUMe right? :)

[@elliott8175]

@@chrisjust7445 Hmm. Knowing was is a "small piece of the puzzle" would also require similar assumptions, no?

[@chrisjust7445]

@@elliott8175 I watched the video 2 years ago, so I don't remember exactly what I originally replied to, but like you said, you need to document the requirements for the basic skeleton of the program first. I think my point was that after that, once you start breaking down the stories and working on them, you should document the requirements in further detail at that point.

[@SargsyanGagik]

What is the minimal or maximal full cycle of deliverable, in time?

[@mortenbork6249]

I think maybe you arent learning the right lesson from your experience. As "uncle" bob Martin says. Defer as many decisions on your architecure as possible. So you dont lock your choices before your client has specified them. Going full circle and documentation are not directly linked. I think in the case you came away with the wrong lesson.

[@richardnipples7574]

tfw you spend 3 months building a cms. This would've made it possible to build in modules and have something to show at early stages.