As i consider TPS and its philosophies, it seems easy to apply them to software development. Perhaps not completely and literally in every case – but it ways that make major improvements.

For example, continuous build and test systems (continuous integration is what they are sometimes called) fits wonderfully in to TPS. Coders can flick their code in to the system and get results back quickly, also the code base can be built and tested automatically and the results placed in emails, on a screen etc etc.

As a perl coder, we have a strong suite of testing software. Even tests to test that our test cases test everything in our code! Tests that check for best practises, documentation coverage (pod) and code tidiness, both of which can be easily customized. These can be easily built in to a system which falls in to the TPS philosophy.

Platforms like ‘github’ also have lowered the entry level for trivial updates, making forking, updating and then pushing the changes really trivial. Such a system allows programmers to easily make small files and improvements in a controllable manner. I think this is again, another concept that is true to TPS

I would love to hear how other people have applied TPS to IT systems and software development. I dont think there is a right or wrong answer, TPS is all about what works for you!

thanks for your feedback. You can see if the pair is blocked from afar by their voices and postures; but this is apparent only if you are experienced enough to tell the difference (for instance) between being busy and achieving little, and programming productively; or between aimless discussion, and focused problem-solving.

There are some objective indicators you could use; you could check, for instance, how long since last commit, or how long since last “green” in JUnit. These indicators are highly dependent on your team’s practices. What do you think?

Interesting thoughts on how to visualize issues in a week.

Best,
Peter Saddington
http://www.whitebarrel.com/blog