Link to the audio:
After listening to the podcast of Ken Beck, I had some ideas and wrote some things I learned.
People ARENT convinced that being agile, iterating, making small commits, that are so important, they think its not so necessary.
Some people think that first you have to figure out what you have to do, then do it, and its done. Mostly it doesn’t work, but in my opinion it’s a life lesson that we have to go through to learn.
If someone is working on something (like code or other thing) if you break it or crash it, it’s the responsibility of the person to fix it. Some fear to break the code, but in some cases its need to break to become better.
But this doesn’t mean to beak things for fun, be smart and think what moves you are going to make.
They also talk about Workflow, wich consist of an orchestrated and repeatable pattern of activitys, enabled by the systematic organization of resources into processes that transform materials, provide services, or process information.
In computer way, its the way you work to get the code to function or to found if it works properly.
One of the topics that they mensioned that called my atention was the Test commit or revert.
It is where every time the tests run correctly the code is committed. It is suguested that suggested that if the tests failed the code should be reverted. But I think a part should be that if the tests fail, then the code goes back to the state where the tests last passed. But that can cause a lot of problems and time lost. Sometimes it can be something little.
We are human and we make mistakes.
If you don’t want a bunch of code wiped out then don’t write a bunch of code between greens. Yes it can be frustrating to see code disappear but you almost always find a better, surer, more incremental way of doing the same thing.
This is where they talked about Limbo, wich scales technical collaboration by propagating tiny changes instantly. TDD won’t work in Limbo because each of a hundred thousand programmers can’t saddle all the other programmers with even one failed test. If thousands of tests are failing, then nobody knows what’s going on.
«Make smaller changes, in a stable way»
One of the last things where tips, on how to make a good program, wich I myself have learned in the years. Here are some: (wich they also talk about)
- Write Useful Comments.
- Use Meaningful Names
- THINK before coding
- Use Automated Build Tools.
There are many more, but this are the one´s that I first though about.
Good luck and never give up.
Testing 