`
| |
|
Archive for the ‘Programming’ Category
Sunday, August 15th, 2010
You’ve heard about limiting WIP (Work-In-Progress) but how good are you at limiting red time? Red time is when you have compilation errors and/or failing tests. A growing group of practitioners have learned how to effectively reduce red time while test-driving and refactoring code. To understand how to limit red time, it helps to visualize it.
In this talk, I demonstrated various strategies to limit your time in Red. We also analyzed a live programming sessions using graphs that clearly visualize red time. Participants learned what programming processes help or hurt our ability to limit red time and gained an appreciation for the visual cues that can help make you a better programmer and fellow member of the Limited Red Society.
Slides from the Presentation:
Posted in Agile, Continuous Deployment, Programming, agile india, post modern agile | View Comments
Thursday, July 15th, 2010
From

To

Posted in Design, Programming | View Comments
Sunday, July 4th, 2010
At the Agile Bengaluru 2010 conference, Sai Venkatakrishnan and Harikrishnan express their concern on the monotony that has crept into the way we develop application and how it affects us being Agile.
We follow agile, but are the systems we are building Agile?
Posted in Agile, Community, Conference, Product Development, Programming, agile india, post modern agile | View Comments
Saturday, July 3rd, 2010
During the Agile Bengaluru 2010 conference, J.B. Rainsberge, in his Keynote highlights the top 10 things he wished people would stop doing on Software Projects.
Posted in Agile, Community, Conference, Programming, agile india | View Comments
Thursday, June 17th, 2010
Mike Bria of InfoQ interviewed me yesterday to find out what is happening with SDTConf. Here is the interview notes on InfoQ. Enjoy!
Posted in Agile, Community, Conference, Programming, Testing | View Comments
Sunday, June 13th, 2010
Posted in Agile, Conference, Programming | View Comments
Friday, June 11th, 2010
Usually when I’m wrapping up my 3 day TDD Workshop, I make it clear to the participants that they will have to deliberately practice, every single day, for a few years, to get better at TDD. In addition to practicing on their own, on pet projects and on production code, I also suggest they take 2 hrs every week on a fixed day of the week, as a whole team, to practice Test-Driving (TDD) the same problem as a team. During these sessions, I strongly recommend people practice Pair programming also.
Logistics: Before the meeting, one of the team member sends out the problem to everyone. On practice day, the whole team gathers in a conference room/team area, picks a pair, sets aside 90 mins to TDD the problem. After 90 mins, few pairs do a quick code walk-thru and explain their solution with important decisions they made during the session. Followed by an open discussion. I also recommend everyone checks-in their code in some common repository, so it can be used for reference by others.
Sample Problems: Next big question is, what problems do we use for Test Driving?
Usually I recommend starting with simple programs like:
Once you’ve done enough of simple programs, then I would suggest you take some large design problems from DesignFest and try TDD on them. The beauty of these problems is, they are quite big, can take up-to a week to finish it completely. Now we are talking real world, where
- We have limited time to solve/program large complex problems which needs to be simplified.
- Try to find a relevant System Metaphor that can help you visualize the design
- Do a quick and dirty, low-fi Interaction Design to understand how the user will use this
- Identify and prioritize the crux of the problem, figure out what is the most important, what will give us fastest feedback
- Further thin-slice the identified piece of functionality and
- Then try TDDing it.
This will truly help you get better at:
Deliberately practicing this way for a few years, even though you are practicing TDD on your production project, will really help you appreciate the depth and benefit of this approach to development.
Posted in Agile, Coaching, Design, Programming | View Comments
Saturday, May 22nd, 2010
I’m planning the Simple Design and Testing Conference (SDTConf) for the first time in India around end of June.
SDTConf is:
- All Practitioner conference (No Jokers giving lectures)
- All Open Space (discussions and lots of hands-on workshops)
- Invitation Only Conference
- I’ve organized this conference in the US for the last 4 years.
Posted in Agile, Conference, Design, Programming, Testing | View Comments
Friday, May 14th, 2010
Just because you know the syntax of a programming language, does not mean you know programming
Just because a toddler can make some sounds, does not mean she can speak
Similarly, just because you write tests before you write code, does not mean you know TDD.
TDD is a lot more than test-first. IMHO, following concepts let’s you truly experience TDD:
- Evolutionary Design,
- Acceptance Criteria,
- Simple Design,
- System Metaphor,
- Thin Slicing,
- Walking Skeleton/Tracer Bullet and
- Interaction Design
How long does it take a dev to be well-versed with TDD?
Depends on the dev, but atleast a couple of years of deliberate practice on projects
What can we do to become TDD Practitioners?
Start with deliberate practice in safe env. Then gradually start on your project.
Posted in Agile, Programming | View Comments
|