When confronted with Legacy code, we usually run into the Test-Refactor dilemma. To refactor code we need tests, to write tests, we need to refactor the code.

Some people might advise you to invest time upfront to create a whole set of tests. Instead I recommend that every time you touch a piece of legacy code (either to fix a bug or to enhance the functionality), you perform a couple of safe refactoring to enable you to create a few scaffolding tests, then clean up the code (may be even test drive the new code) and then get rid of the scaffolding tests.

Even though this approach might appear to be slower, why does this approach work better?

• You start seeing some immediate returns.
• On any given system, there are parts of the system which are more fragile and needs more attention than others. There are parts of code which we actively touch and others we rarely touch. When we have a limit time, it does not make sense in investing effort to create tests for areas that are fairly stable or rarely changed. Big upfront test creation might not take this aspect into account. So you might not get the biggest bang for your buck.
• The first few tests we usually write are fragile tests. But we won’t get this feedback nor the opportunity to improve the quality of our tests until its too late.
• When we get into a test creation mode, everyone is focusing on creating more and more tests. Finally when we start using the tests we’ve created, a small change in production code might breaks a whole bunch of tests. First few times developers wonder what happened, but if this generates a lot of false-negative (which usually they do), then developers start ignoring or deleting those tests. So the investment does not really pay for itself.
• Also when we have a whole lot of tests prematurely written, they start getting in the way of refactoring and genuinely improving the design of the code. (Defeats the whole point of creating test upfront so we can refactor.)
• People get too attached to the tests they had written (it was a big investment). They somehow want to make the test work. People fail to realize that those fragile tests are slowing them down and getting in their way.
• Unless the team gets into the habit of gradually building better test coverage, they will always play the catch up game with requirements constantly changing. (Remember we are chasing a moving target.)
• Its usually hard to take a fixed (usually long) duration of time off from CRs and bug fixes. People will be forced to multi-task.

I encourage you to share your own experience.

Technical Debt is any technical issues slowing down the project due to hasty (short-sighted) decisions made at an earlier point.

All of us make bad decisions, but not fixing them and just differing them really leads to bigger problems as these issues have a snowball effect.

Technical debt can be introduced at various levels:

• Code smells is the most obvious one,
• But things like lack of (or poor) automation,
• poor choice of tools,
• fragility in the development environment
• and so on

can also contribute to technical debt.

How good are you at limiting red time? .i.e. apply limiting WIP (Work-In-Progress) concept to Programming and Product Development.

What is Red Time?

• During Test Driven Development and Refactoring, time taken to fix compilation errors and/or failing tests.
• While Programming, time taken to get the logic right for a sub-set of the problem.
• While Deploying, downtime experienced by users
• While Integrating, time spent fixing broken builds
• While Planning and Designing, time spent before the user can use the first mini-version of the product
• And so on…

Basically time spent outside the safe, manageable state.

Let it be planning, programming or deploying, a growing group of practitioners have learned how to effectively reduce red time.

For example, there are many:

• Refactoring Strategies which can help you reduce your red time by keeping you in a state where you can take really safe steps to ensure the tests are always running.
• Zero-Downtime Deployment which helps you deploy new versions of the product without your customers experiencing any downtime.
• Continuous Deployment which helps you get a change made to code straight to your customers as efficiently as possible
• Lean Start-up techniques which helps validate business hypothesis in a safe, rapid and lean manner.
• And so on…

I highly recommend watching Joshua Kerievsky’s video on Limited Red Society to gain his insights.

Over the years we’ve realized that it always helps to have simple tools to visualize your red time. Visualization helps you understand what’s happening better. And that helps in proactively finding ways to minimize red time.

At Industrial Logic we have a new product called Sessions which helps you visualize your programming session. It highlights your red time.

On many applications I’ve worked on, Authentication is a big pain.

• Usually its an usability hazard. (No one likes to authenticate themselves over and over again)
• Since its a cross-cutting concern and every application has some special logic for authentication, we spend way too much time hand crafting the best strategy to implement and test it to make sure our application is secure.
• When you have multiple applications and you want to implement single-sign-on, the pain just exponentially amplifies.
• On high scalability apps, Authentication (session validation) can be expensive from performance point of view

In the search of simplicity, I’m wondering if there are alternative techniques to implement authentication on certain types of applications.

One thought comes to my mind, which I’m curious to try. I’ll start with a very specific example and then expand it to other applications.

While building web applications in the category of social networking or eLearning or some other category, where retrieving data from the app is not very critical from a security point of view:

Even if you have a stale session cookie, GET request works fine without requesting you to authenticate. Only when you POST, authentication kicks in.

This approach will certainly not work for a banking application, where reads also have to be very secure. But for many application reads don’t need to be very secure. Also most applications have relative very small number of POST requests, which means very few times the user would be nudged to authenticate themselves. Most RESTful frameworks can have this built in.

Can this approach be used for rich-client apps instead of just web-apps? I think so.

What am I missing?

I’m proud to announce the 5th Annual SDTConf. This year we plan to hold the conference in Otterbein University Campus Center, OH, USA.

We plan to keep a max cap of 100 participants for this conference.

As you might be aware SDTConf is a free conference and we use the concept of position papers as the price for admission. This helps us ensure the quality of the participants is really high. You can add your position papers for the conference on our wiki. Making the position papers public helps other participants gauge in advance what they can expect from the conference.

Last but not the least, since this is a community run, non-profit event, we really on sponsorship in kind to make this event possible. Here is a list of items that you or your company can sponsor to support this conference.

P.S: Please blog about this conference and/or send an email to your friends and colleagues. Word of mouth is the only way we market this event.

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 development 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 developers and fellow member of the Limited Red Society.

Slides from the Presentation:

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?

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.

This post is moved to Industrial Logic’s Blogic.