free html hit counter
Posted on: Wednesday, January 2, 2008 by Rajiv Popat

Breaking The Infinite Loop Of Failure

Tom DeMarco and Timothy Lister start their book Peopleware – Productive Projects and Teams, with a thought worth harping on:

Somewhere Today, A Project Is Failing.

Since the days when computers first came into common use, there must have been tens of thousands of accounts receivable programs written. There are probably a dozen or more accounts receivable projects underway as you read these words. And somewhere today, one of them is failing.

Imagine that! A project requiring no real technical innovation is going down the tubes. Accounts receivable is a wheel that's been reinvented so often that many veteran developers could stumble through such projects with their eyes closed. Yet these efforts sometimes still manage to fail.

Software Legend Steve McConnell throws some light on the same mistakes people in our Industry have been making again and again, so many times, for so many years, that he calls them Classical Mistakes.These are the kind of mistakes which can easily cause yet another simple accounts receivable project to fail once again.

Both, the thought of an accounts receivable system failing and classical mistakes are thoughts that have some sarcasm, irony and a lot of bitter truth in them. Both these thoughts are in-fact quite scary if you harp on them for too long. And then you begin to wonder why.

Why do the same kinds of projects keep failing over and over? Why do programmers keep making the same kinds of mistakes again and again? Why can’t programmers of this planet, for once, spend some time and learn how to program?

DeMarco and Lister provide a clue to the alert reader who can read between lines and come to his own conclusions in their book:

The statistics about reading are particularly discouraging: The average software developer, for example, doesn't own a single book on the subject of his or her work, and hasn't ever read one. That fact is horrifying for anyone concerned about the quality of work in the field; for folks like us who write books, it is positively tragic.

Notice the use of the word horrifying? Yes, it is in fact much more than just horrifying.

It is a well known fact that today most folks in the business of crafting software don't give a shit about learning the craft of building good software and the sorry state of our industry allows them the luxury of staying blissfully ignorant.

Software Development as it stands today, is probably the only field where you can afford to be the man responsible for the failure of multiple accounts receivable systems and be rest assured that there will be a body-shop out there willing to hire you at a higher salary and a better designation to give you the job of building another accounts receivable system just because your resume says you worked on multiple accounts receivable systems. 

I do not know why or how but an obsolete version of my resume which has not even been touched, updated or posted anywhere in the past five to six years, keeps fetching me job offers, interview calls and emails from Indian body shops which I politely keep turning down and sometimes even ignoring.

It’s tragic.

Not because someone somewhere out there wants to hire me. That’s the good part. There’s nothing tragic about that. It’s the best professional complement you can receive as a software developer. This year for instance I received a couple of offers from folks who knew me or folks who had read this blog, had read one of my articles, had taken the pains to get my references from folks I had worked in the past and then decided to make me a job offer. Even though I turned them down, the offers did come as professional compliments which ended up making me feel really good.

Having said that however, most other offers I ended up getting this year have been from complete strangers, based out of an obsolete outdated resume that has neither been updated nor posted anywhere for over five to six years! The fact that there are recruiters out there working for so-called-big-body-shops who want to hire me, without knowing anything about me, based on a resume which hasn’t been updated in the last five to six years, speaks at-length about the recruiter, his desperation to find anyone who is ready to call himself a programmer, the shortage of programmers in our business and the desperation of the organization he works for.

And, that is in fact both tragic and scary.

I even have a name for this type of a software-development-eco-system which constantly encourages crappy programmers to enter the industry, make classical mistakes and keep failing project after project. I call this the Infinite Loop of Failure.

The Infinite Loop of Failure explains why another simple accounts receivable system can manage to fail even after the millions of man-hours of computing experience our industry has behind it. Let me illustrate the Infinite Loop of Failure using my artistic skills:

A huge part of the universe in which we live in includes:

  1. People who build software – we refer to them as programmers; depending on their way of working, sometimes I address them as bodies, so-called-programmers or even Fred.
  2. People who hire people to build software – we refer to them as companies or employers; depending on their way of working, sometimes I also address them as body-shops.
  3. The People who ultimately pay, to get software built – we refer to them as clients; these are people who know nothing about building software, have one or more bitter experience with software development from their past where they've been bitten by some body-shop and a bunch of clueless bodies. Now they want to spend as little money as possible. These are people who need help in getting their problems solved by building systems that work.

I write this post with a heavy heart, but the fact is that most of the people who form these three categories are totally lost and looping around at different stages of the Infinite Loop of Failure playing different roles in the loop’s infinite life cycle. They are in-fact helping the loop gain momentum and stay alive.

A huge part of our industry, is doomed to a future where the same kind body-shops will keep recruiting the same kind of programmers, who will keep making the same kind of mistakes on the same kind of projects, using the same crappy processes and methodologies and will keep meeting the same kind of failures. As you read this post, a huge number of so-called-programmers are spending their lives looping in this Infinite Loop of Failure as they hop from one job to another, one designation to another and one project to another, earning peanuts more for every hop.

What makes the problem difficult to solve however, is that this multitude of so-called-programmers is largely un-reachable and cannot be helped by posts like this one. You can’t get them to know about this Infinite Loop of Failure. They are not exactly reaching out for technical blogs, reading posts like this ones, writing their own posts, learning how to become a better developer, participating in user-groups, asking or answering questions in forums or buying copies of Code Complete, Pragmatic Programmer, the Software Project Survival Guide and the like. Long story short, they don't care - because our Industry allows them the luxury of not caring and getting away it. 

I’ve met my share of 501 programmers around the world and I've also met my share of programmers who are so depressed about programming that they write depressing poetry.

I’ve had my share of failures as I pushed budding college students to read and write blogs, pushed budding project managers to read Software Project Survival Guide and pushed budding programmers to read Code Complete.

Most of them are usually too busy to read a book, read a blog or start their own blog. They are too busy firefighting their current project which is doomed to fail because they are making the same classical mistakes. Others are busy playing musical chair with their jobs. They are standing right on the edge of the Infinite Loop of Failure preparing to enter it.

I've had my share of failures as I try to nudge them to the brighter side and try to stop them from entering the loop. Some don’t even make an attempt to read a book, blogs or start their own blog. Others start for a couple of weeks - under the gush of enthusiasm, at times even just to impress me - and then stop. I've seen multiple other colleagues at work fight this same battle of motivating the unmotivated programmers and face the same problems.

If you’re trying to convert a programmer who has already entered the Infinite Loop of Failure and is addicted to going around in circles, it’s usually a losing battle, at-least a very difficult one. Having said that, I agree that that we need to continue motivating the masses and keep trying relentlessly to pull the ones walking on the thin line of the loop to the brighter side of the line.

It is a fact that these masses consist of a huge percentage of our industry, and if they don't care about software development, if you think logically, it translates to a very strange fact:

A huge percentage of the people in the craft of building software do not give a shit about the craft of building software.

And that is a scary thought. Don't you think?

But there is a silver lining to the dark cloud. The sorry state of affairs in our world of software development makes it really easy for shameless thick-skinned programmers like us, which includes me who is writing this post, and you dear reader who cares to read it, differentiate ourselves as one man armies or kick ass programmers and shine.

We can distinguish ourselves very easily! Not because we write code that no-one else can write but because we know that most of the times we write shitty code with bugs. Because we know that the Infinite Loop of Failure exists! We also know that this loop can be broken by exchanging thoughts through books, sharing ideas through blogs and learning from not just our own mistakes but from the mistakes of the people we work with and share ideas with.

We know that, to break the Infinite Loop of Failure all we have to do is find a job we love, join a team we love working with, stick to developing deeper roots and in the process have loads and loads of fun doing what we always loved doing – which is building software that is nowhere close to perfect, but that ships, gets the job done and keeps improving and getting better with us

Of course, we are no different from the ones who do not care and yet so very different. Just like them, we are bound to make mistakes. Some of these may be small, some may be colossal. Some can be fixed; some cannot be fixed for life and will keep us wishing if only we could go back in time and fix them. But every single mistake will at-least teach us a lesson and turn us into better individuals. Mistakes are good, as long as we stop making the same old lame mistakes and make all new ones; As we make all new mistakes we are bound to keep learning something from these fresh new mistakes and that knowledge will eventually keep us out of the Infinite Loop of Failure.

As Jeff Atwood points out in his post:

I say the more failed projects in your portfolio, the better. If you're not failing some of the time, you're not trying hard enough. You need to overreach to find your limits and grow. But do make sure you fail in spectacular new ways on each subsequent project.

So, do you know a couple of folks who could never ship a module on time but who managed change three jobs in the last one year? Do you know folks who never cared to read a book or a blog but were happily failing one accounts receivable system after another? Or do you know a few developers who are basically smart but standing on the edge of Infinite Loop of Failure? Jeff Atwood's suggestion on reducing daily WTF snippets might turn into a beautiful New Year’s gift you can buy them this year:

Let's take a break from our regular programming to consider how we can prevent WTFs from happening in the first place. If you're reading this, you probably don't need our help. But your fellow developers do. Take less capable developers under your wing. Mentor them. Provide them with guidance. Invite them to a user group meeting. Email them blog links. Expose them to essential programming books like Code Complete and Don't Make Me Think. In extreme cases, maybe they legitimately picked the wrong profession and should be gently nudged into some other role.

Go buy them a copy of Code Complete before it’s too late. If they do read it, nudge them to read a couple of blogs and push them into starting their own blog. Show them the path to shamelessness. After all, in the years to come, we don’t need more failed accounts receivable systems, do we? Who needs more Daily-WTF Code Snippets in our project code-bases? I don't. Do you?

As a new year rolls towards us, let’s continue relentlessly trying to help the programmers walking on the thin line of the Infinite Loop of Failure move over to the brighter side.

As for us, you dear reader and me – people who care to reach out for books, blogs, user-groups, web-casts, open-source code-bases, fellow-developers, colleagues or any other source under the sun that can help then become better developers and better individuals, let’s continue to break the break the Infinite Loop of Failure, this year and year after year. Not because we want to change the world, but because we know that it can be broken and because we can have fun breaking it

Dear reader, this new year, I wish you luck. If you’re going to be making mistakes, I wish that you make all new mistakes. And by the way, this year, as you slog away at becoming a better developer, a better professional and a better individual, day after day, don’t forget to play your part in breaking the Infinite Loop of Failure. You owe it to your profession, you owe it to your fellow programmers and above all, you owe it to yourself!

posted on Wednesday, January 2, 2008 2:03:46 AM UTC by Rajiv Popat  #    Comments [0]
Posted on: Friday, December 28, 2007 by Rajiv Popat

Is Your Task Done? Or Just Ninety Percent Done?

We all love progress bars. Whether it involves copying a simple file, attaching something to a web based email or installing something on our machines - as human beings we like the idea of being in control. We like to be informed about:

  1. How much of the work is done.
  2. Home much of the work remains.
  3. How much more time will it take to get remaining job done.

All we expect from progress bars is simple, definitive, true and honest answers to the above three questions. That is all we want from them. No More.

And at the first glance progress bars seem to suggest that they will in fact live up to our expectations. I mean, look at the one below. Doesn’t it say out loud that it is in fact, going to keep you informed about the answers to all of the above three questions?


Now go on, start another file copy process, then another. Then open up your Outlook and a couple of Microsoft Word instances and watch this progress bar get utterly confused.

Steve Teixeira in his post, describes how, in the web world now a days, true and honest progress bars are difficult to find. In fact he believes that progress bars have ended up being nothing more than a lie that we all accept. He explains the basic fundamental issue with progress bars back from the Windows 95 days using an application installer as an example:

I remember my first exposure to this temporal dissonance while installing some software on Windows 95. The user interface provided a few vague textual messages about what was happening as the progress bar ranged from about 0 to about 90%. This took about 10% of the install's total time. During the remaining 90% of the total install time, as the progress bar inched its way the last 10% to completion, the installer provided textual messages with ridiculous detail on what it was doing. It's almost as if the point of the UI widget was to annoy rather than inform. Alas, this form of progress bar remains the most common species found in the wild today.

Ever been through this frustrating experience where you saw the progress bar move up to 90% and then just sit there, mocking the trust that you placed in its ability to report the accurate status of the task back to you?

But the progress bar, by no means, is dishonest.

The simple fact of life is, things changed after it started. Things changed after the progress bar told you that it was 60% done. It needs more time to get the job done and the 1-to-100% window of reporting-the-progress does not allow the progress bar to break one simple fact to you - that it needs more time. Basically, the progress bar feels intimidated to report 180% of 100% work done, so it just sits there at 90%, slogging away.

Now, dear reader, take a pause and think. Have you ever been in a project where you were “almost” done in the first month and took another two months to be “done-done”? If you think about it, you were in fact the progress bar, weren’t you?

Have you ever heard the 90% done status from a team members and then seen them slog away at the remaining 10% for a long time? If you were leading the project, chances are you limited your team in a 1-to-100% window of reporting which did not allow him to break one simple fact to you - that things have changed since they started and they need more time.

While working with projects remember the Famous Quote from Tom Cargill:

The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of development time.

Long story short, it's easy to be 90% done. Difficult to be done-done. As attractive as progress-bar-approach of reporting may sound, expecting the task status to be reported in a windows of 1-to-100% just does not work. Here is why - If you are a project Manager running around the office with a Gant-chart in your hand asking your developers what’s the percentage of their task that is done chances are your project will be successful till it’s 90% done. And then, it'll fail pathetically.

Johanna Rothman in her article provides advice on doing away with the 90%-done-game while reporting your project status. Go ahead, click the link and read the article. It is a good read indeed.

If I try to summarize what Johanna is suggesting in my words, it basically seems to boil down to really fundamental principles of Agile or for that matter, common sense:

  1. Divide and Conquer - Break down your tasks into something you can do in a day-or-two. Something she calls Inch-Pebbles.
  2. Track and Report Your Low Level Tasks In Boolean – It’s either done or not done. And done does not mean just done, it means Meets-The- Definition-Of-Done done.
  3. Introduce Transparency – Allow your team members to become a little more shameless than a progress bar and talk about problems if they are not being able to get the feature done rather than just asking them the percentage of the job done and then hoping problems will fix themselves. If the problems are genuine and cannot be solved in the time-boxed sprints, prioritize and drop features.

Years after the progress bar was born, a lot of programmers figured out that it’s really difficult to answer the three questions progress bars attempt to answer correctly and honestly. The indeterminate progress bar was born. Today, even the smartest of developers around the world, can't give you a percentage-complete for everything and it sure does look like they are not ashamed to admit it: 


So why are you?

On a serious note, Trying to report individual task progress in percentage done and expecting the team to provide you with "percentage complete" numbers in a bi-weekly / monthly status meeting, is an obsolete project management technique that never worked even when it wasn't obsolete. If you have divided your tasks well, everyone knows where your project stands and most of the times your tasks, sub-tasks, inch-pebbles or whatever you choose to call them, are either done or not done. 90% done is as good as not done.

Next time you report your tasks, instead of percentage, try using boolean for task statuses. Get together as a team everyday and take an inventory of how many tasks / sub-tasks / inch-pebbles are done. Try prioritizing and respecting the iron triangle by dropping features if necessary. Chances are you’ll fail early and you'll fail often but in the end, if you keep reporting your tasks in boolean you’ll reach the hundred percent mark, successfully.

So dear reader, what are you working on today? Are you going to be done soon? Or just 90% done?

posted on Friday, December 28, 2007 7:27:52 AM UTC by Rajiv Popat  #    Comments [2]
Posted on: Thursday, December 20, 2007 by Rajiv Popat

Broken Windows - If Broken They Are, Fix Them You Must.

Tess’s Blog Title provides profoundly important advice to every developer - “If broken it is, fix it you should” – Words of wisdom, which are much more important than they would sound the first time you hear them.

A young an enterprising engineer recently looked at one of our code base and asked me why we use interfaces and abstract classes so extensively when we could have coded using code-behinds in ASPX pages.

Another engineer I worked with in the past often wondered why I sent out long and loud emails to team members when I discovered they were using band-aids to mend their code and were moving on to new functionality without fixing small problems and issues resulting out of their using these band-aids.

Another young college graduate fresh out of college, who I worked with in the past also, believed that I often strive for – “perfection for the sake of perfection” – and questioned why I push developers to use Re-sharper, CodeRush or other similar tools.

The answer to all of these questions and why I strongly insist on every developer developing a certain sense of responsibility towards writing clean, small, cohesive and maintainable code can be summed up in two words – “Broken Windows”.



The Broken Windows theory has been rather old but I continue to be amazed at how much influence it has, on both – software development and our lives in general.

For the last couple of weeks, during my stay in a hotel suite in San Francisco, I was working working a client during the day time and a small but very smart team back at work during the late evenings. A lot of work was leaving me way too tired to cook and I had primarily moved to frozen food, vegan broccoli hot-pockets, chips and snacks – all of which came in plastic packets.

The first time I used the frozen food I left the empty plastic packet on the cooking shelf because I was way too tired to thrash it. The next day, I was tired again and history repeated itself. Soon packets started piling up on my kitchen shelf. The housekeeper stopped cleaning the kitchen and in a matter of less than a couple of weeks plastic packets started showing up in my entire suite making it look like a thrash-room. This in turn started making me feel very depressed every time I returned to the suite from work.

What I had experienced first-hand, in my very own life, was a classic example of the Broken Windows Theory in action.

As someone who has read about this theory many-a-times and has tried his best  to keep this theory from becoming a reality in his projects, I keep getting amazed at how the broken windows theory does in fact, starts affecting us, both in our projects and our lives, every time we leave just one little broken window unfixed.

Broken Windows can destroy lives and projects faster than most people think they can.

Andrew Hunt describes the Broken Windows Theory and why it is dangerous to live with Broken Windows in his book the pragmatic programmer and his online interview. He describes the basic theory much more articulately than the little hotel suite example from the recent past I described above. He explains:

Researchers studying urban decay wanted to find out why some neighborhoods escape the ravages of the inner city, and others right next door - with the same demographics and economic makeup - would become a hell hole where the cops were scared to go in. They wanted to figure out what made the difference.

The researchers did a test. They took a nice car, like a Jaguar, and parked it in the South Bronx in New York. They retreated back to a duck blind, and watched to see what would happen. They left the car parked there for something like four days, and nothing happened. It wasn't touched. So they went up and broke a little window on the side, and went back to the blind. In something like four hours, the car was turned upside down, torched, and stripped - the whole works.

Hunt in the same interview gives another example:

They did more studies and developed a "Broken Window Theory." A window gets broken at an apartment building, but no one fixes it. It's left broken. Then something else gets broken. Maybe it's an accident, maybe not, but it isn't fixed either. Graffiti starts to appear. More and more damage accumulates. Very quickly you get an exponential ramp. The whole building decays. Tenants move out. Crime moves in. And you've lost the game. It's all over.

Jeff Atwood in his post on this topic brings out a new perspective. He believes that it’s all about perception. He explains:

Programming is insanely detail oriented, and perhaps this is why: if you're not on top of the details, the perception is that things are out of control, and it's only a matter of time before your project spins out of control. Maybe we should be sweating the small stuff.

As developers we all make compromises for the sake of shipping. It's also a hard fact of life that after all, we all make shitty software with bugs.

But here is what differentiates the veterans who have seen the light or have mastered the art of shipping, from the programmers who can’t program.

  1. The Veterans know that they have written shitty software when they have and they are unashamed to admit it.
  2. The Veterans know when and how the shit usually gets out of control and are very careful about fixing the broken windows as soon as they are broken, before things start getting out of control. 

Ever been a part of a project that you wished you were never a part of? Ever been a part of a project where you felt glad that the project ended and felt happy that you could run far away from it?

Look back. Chances are that it all started with one or two broken windows which no one bothered to fix.

Do you have broken windows in your current project? Fix your broken windows, before you yourself and others in your team, start getting a perception that your project is a dumping ground for bad code and start vandalizing your own project, subconsciously, innocently and unknowingly.

For today I tweak Tess’s blog title slightly and leave you dear reader, with a thought worth harping on, for your project and your life - “if broken your windows are, fix them you must”.

posted on Thursday, December 20, 2007 6:18:36 PM UTC by Rajiv Popat  #    Comments [0]
Posted on: Thursday, November 29, 2007 by Rajiv Popat

Is Your Client Your Ally?

One of my first projects as a young developer, who was taking his first steps into software development, was a RUP / CMM / Waterfall text-book example of how successful projects should be run using Big Design Up-front Methodologies. It completed on time, it was on budget and it was transitioned successfully.

We had every single scenario and flow of the system documented. Every single change that was not elaborated resulted in a change request for which the client either ended up paying us more money or giving up the idea of wanting the change.

If you were to consider it a war, we won.

This so-called-success was one the biggest failures in my life as a software developer. A failure that turned me into a Shameless Developer and taught me things I would never have learnt otherwise. Later on I was also called in to support the crap the entire team (me included) had written and the same project also ended up teaching me how to refactor code ruthlessly.

Folks who worked with me in the project wondered why I considered the project a pathetic failure when it was transitioned with a successful UAT and we had a grand lunch to celebrate the project success. Here’s why:

"They’re changing their Requirements!"

"It’s there in the Use-case! Why didn’t they read the use-cases during elaboration?"

"What do they mean it’s just a validation change? It requires quite a bit of code change. I think this is a Change Request!"

"What do they mean by it’s not Quality? All the test-cases have passed, haven’t they?"

"What do they mean it crashes sometimes? They're supposed to give us the detailed steps to reproduce a bug! If they can’t give us the steps to reproduce the bug, we should just go ahead and close it."

Any of these sound familiar?

During the time we worked on this project, dialogues like these were a part of our daily lives. I heard these from team members more than once every day. It was a war and we were in it to win it.

Occasionally we would also hear whispers from the client which went somewhat on the lines of – “Umm… I’m not sure if this feature adds a lot of value” or “I wonder if we can…” – but who cared? We were building as per the approved specification.

We had spent a few odd months writing use-cases, test-cases, module specifications, low level system specifications, system requirement document, functional specifications, technical specifications and tons of other documents a lethal combination of RUP and CMM would require you to write and now we were there to ensure that they either stick to those documents or pay the price if they bothered us with changes while we were busy developing.

We had been constantly firing “them” with pages and pages of these documents, constantly reminding them that we were very organized team of guys who worked according to a systematic process. Anyone watching us, would have guessed that we were building a plan for a bridge, a building or a rocket when all we were building was a shitty piece of software that would hardly ever get used by anyone.

After sleep-less nights, meetings and brute force programming using incompetent mediocre developers, we, the team, delivered the project. The delivery and the UAT was the final blow and we got it over with before the client could even realize what the hell happened.

Things like usability, user experience and the like were never documented. So when they would come up asking us to reduce the number of clicks, we showed them a functional specification document, told them it was a change request and asked for more money.

More often than not they chickened out, which was good because we could comfortably meet the time-line. If they paid more money and wanted the change-request done, we would ask for more time and that would still allow us to comfortably meet new dead-lines.

After a few months of rigorous fighting, the project was on time and successful.

The client was defeated.

And that, by the way, is precisely why I consider the project a pathetic failure.

When I completed that project, the feeling of being a part of a team that had failed at achieving their fundamental undocumented-goal of building a system which is usable, wasn't particularly amusing. The fact that no-one in the team had even realized how badly they had failed, made things even worse. I went ahead and made a commitment to myself that I was going to get better at building good software and providing true value to my clients project after project.

When I made the commitment to myself, I thought that this is the lesson every programmer out there, who has been in the business of building software for more than a few kilo-seconds, must have learnt this same lesson the hard way. After all they don’t seem to teach these things in programming schools.

Years later today, I've lost touch with everyone from that project team but even today, all over the world, I see countless developers with years of work experience behind them, fighting their wars against their clients and winning every single one of them, one after another. With one war over they move to another and then another. Defeating client after client, not caring or giving a dam about developing deeper roots or getting better at what they do or even attaining enough skills to be able to provide true value to their clients.

Take a trip some of the larger software consultancy body shops in India and look around. You’ll be able find complete battalions of guys who specialize in RUP / CMM / Waterfall documentation which can even confuse veteran developers leave aside unsuspecting clients.  Walk down the corridors of these shops and you'll see developers talking about - SRS, FTC, UTC, CRQ  and countless other abbreviated document names, but you'll hardly hear them having white board discussions on how the code or design can be improved.

Everything, ranging from the abbreviated document names, long winded processes, bulky documentation which has no respect for DRY, code and design done with contempt for KISS and Orthogonality, is focused towards one goal – defeating the client in a war.

A huge number of these guys have been trained into believing that Big Design Up-Front is the only way to build software and that if a company isn’t doing RUP or CMM, it probably doesn’t know how to build software and if a team does not cross the size of twenty people they are not really building a good software. Every once in a while I will interact with folks from these body-shops - folks with a mind-set who believe that If a guy talks about backlogs, daily scrums and weekly iterations through sprints and particularly getting the client involved in active feedback, he probably is an alien who is contaminated with the Agile virus.

No wonder more than seventy percent of the software that is built, fails. No wonder software professionals are the most hated group of professionals in the world after lawyers. :)

Almost instantly after my first so-called successful project, I turned into a thick-skinned developer who fails early and fails often and started working for organizations / clients / managers who, till date, thankfully, have allowed me to fail early. Failing early in projects all these years has allowed me to be a part of projects which both the client and I can consider – successful.

Every single project that I’ve worked on since then, has been a war against time, a war against badly written code, a war against huge complexities and a war against so many other things, but thankfully, not a war against the client. I sure do hope things continue that way for me, project after project.

This is not about how you build software or your development process. After all, we all build shitty software. This is about "working with your clients" and providing them value for money. If you want to come remotely close to winning the battle of building decently acceptable software, you may want to start by having the client on your side.

The next time you write a thirty page functional specification for the login screen, followed by a twenty page login test case and send it to the client asking them to review it in a couple of day, ask yourself if you’re really helping them. Would they rather by happy seeing wire-frames followed by a quick five minute recorded screen capture video where you run them through mockups and re-iterated their requirements? Can you spice up your functional specifications and tempt your clients into reading them? Maybe they appreciate slightly  better ways of capturing functional specifications - How about trying to convert you functional specifications to a wiki?  

The next time the client tells you they can’t send you the steps to reproduce that bug, maybe you might want to do a code review on that module and check out if there’s an erratic bug hiding somewhere.

The next time all your test-case documents come back executed successfully from the Quality Assurance but the client is still not happy, maybe you might want to increase the code coverage your QA teams are testing. You may even want to consider writing a few Unit Tests to test your code and growing the number of tests over time to increase coverage.

The next time the client asks for a tiny business logic change and you find yourself complaining that they should have said that before - maybe you could have done a better job at making it configurable rather than leaving it hard coded in there. Maybe you never cared about Orthogonality.

Ask yourself - Are you sending out builds frequently? Can your client run your builds? Are you seeking constant feedback? Are you iterating fast enough?  

Rather than spending hours in building support for law-suite in our processes and documentation we as developers would be much more loved and respected by our clients if we spent this same time building good software and making life simpler and better for them. Confusing the client with documents is easy. Simplifying their life and building software that adds genuine value is hard.  

In the war of building good software, you have enough to fight against. Don’t rage a war against your clients. Make them your allies.

posted on Thursday, November 29, 2007 7:57:37 PM UTC by Rajiv Popat  #    Comments [0]
Posted on: Sunday, November 25, 2007 by Rajiv Popat

TacticSheet New Features - Announcement 3

For those of you who still don’t know what TacticSheet is – TacticSheet is a Free and Open Source Timesheet and Expense Tracking system. If you want more information about TacticSheet you can click here.

I've been busy at work for the last couple of weeks. I've also been traveling for a couple of days last week primarily for work but none the less, we’ve been putting in quite a bit of time every weekend on TacticSheet. I'm happy to say that TacticSheet is slowly and steadily starting to shape up decently well.  For the last two weeks we were a little slow at adding new features but we've been taking one step at a time and making sure we don't burn out in the long marathon ahead.

Here are some new features that have been rolled out based on the work we did last weekend and this weekend:

Introduction of 'Clients'

TacticSheet now allows you to add your clients to the system. Once you’ve done this, while adding a project TacticSheet will let you group and create project under a given client. In the long run this is supposed to allow us to answer multiple questions. For Example:

  1. How many clients does my organization have?
  2. How many projects are under each client?
  3. How many employees are dedicatedly working for a client?
  4. How many man-hours has the organization put in behind one client and their multiple projects?

Adding the concept of allowing you to add clients in the system and then group projects under each client opens up a host of possibilities for TacticSheet in the future. We're also hoping that it would help integrate with accounting and billing systems in the long run.

Introduction of 'Tasks'

For a day job, to earn my daily bread and butter, I work at an awesome software shop. We estimate each task for a project that we work on. Then we let folks take ownership of the task and work on the task. Once the tasks complete we go ahead and compare the estimated time with the Actual Time taken and this comparison allows us to get better at our future estimations.

Now TacticSheet allows you to store tasks under each project and allows employees to file their time against a task instead of a project.

This is supposed to open up new dimensions for TacticSheet once we move into reporting. Having this data in place will allow TacticSheet to answer questions like:

  1. How many employees worked on a given task?
  2. How many man-hours of work went into a given task?
  3. Which task in the project took the maximum amount of effort to complete?

Percentage Allocation and Percentage Criticality Captured During Allocation

In the last check-in we added the ability for enhanced employee allocation to projects into TacticSheet. In this check-in we also allow you to capture additional facts about the allocation:

  1. Percentage Allocation of the Employee – In a lot of organizations I’ve seen employees being allocated to more than one project at a given time. Now in TacticSheet, while allocating an employee to a project you can not only choose the time-line for which he will be allocated to the project but you will also be allowed to pick the percentage of his time you typically want him to give against the project.
  2. Percentage Criticality of the Employee – In a lot of organizations I’ve seen employees being assigned to a project to complete ad-hoc tasks. At times I’ve also seen employees being assigned to a project because they’re on the bench and having nothing else to do :) – Now in TacticSheet, while assigning an employee to the project for a given duration you can also choose the criticality of the employee to the project. A high criticality indicates that moving the employee out of the project might considerably impact the project and a low criticality indicates that the person can be moved to another project if he is really needed in a different project. In other words, a low criticality indicates that the employee is not critical in the project and moving him from the current project will have no or very little impact on the current project.

Minor Bug Fixes

An issue with TacticSheet with multiple connection strings being used by TacticSheet was reported in this thread of our mailing technology mailing list. We’ve gone ahead and fixed it.

What’s next?

More Features - good software is never complete and we’ve hardly started yet. More features, posts and goodness coming up! Stay tuned!

posted on Sunday, November 25, 2007 5:15:40 PM UTC by Rajiv Popat  #    Comments [0]
Posted on: Monday, November 5, 2007 by Rajiv Popat

TacticSheet New Features - Announcement 2

If you are interested in a free open source Timesheet and Expense-sheet tracking system built on C# 3.0, .NET 3.5, LINQ and Orcas Beta 2, you should checkout TacticSheet. A couple of weeks we announced a development version of TacticSheet live. You can read that announcement and learn more about TacticSheet here. We also published our First New Features Announcement Last Week and announced a couple of new features which are expected to add a lot of power to TacticSheet when we move to our first release.

If you're a .NET developer you could go grab a copy of the latest TacticSheet code from TacticSheet Source Forge SVN and start playing around with it. You can also go ahead and join our General Mailing List or the TacticSheet Technology Mailing List.

A lot of new ideas have started coming. I’m bubbling with ideas myself and new ideas are also being thrown at me by folks who are interested in using TacticSheet when it reaches a release ready stage. We’re taking one step at a time and adding a few new features every weekend. Here’s what we’ve added to TacticSheet this weekend:

Enhanced Resource Allocation while Creating Projects

While allocating employees to Project it was natural for me to provide a Move-List in the Edit Project / Project Creation screen so that you would be able to allocate employees to project:

At the first glance the idea seemed good enough for the basic project allocation requirement that we had and made a lot of sense. You could allocate employees to a project and they would work on the project till the project ended. If you wanted to stop employees from filing Timesheets pertaining to that project you could remove them from the project team.

Apparently, it looks like people who have been using commercial timesheets for a long time feel that this is the biggest pain-point of some of the commercial timesheet entry systems.

A commercial timesheet entry system I looked at while playing around with the idea of writing TacticSheet seem to be doing exactly the same thing I did initially with TacticSheet, which is to allow you to either assign employee(s) to a project or unassigned employee(s) from a project.

Last week someone who saw TacticSheet and had used a couple of other timesheet entry was very helpful in giving feedback. He brought it to our notice that In reality, organizations tend to be much more dynamic. Here are some scenarios where the basic assumption that if employees are assigned to a project, they will work on the project during the entire span of that project, creates a nightmare for the administrators:

  1. An Employee will need to work on the project just for the first three months of the project.
  2. An Employee will need to join the project three months after the project started and will work only for two more months after which he will need to be moved from that project into another project.
  3. An employee will be allocated to a project and will work for two weeks in that project. Then he will be moved out of the project and will be needed again for two weeks, three months later.

A couple of commercial Timesheet entry systems I saw while playing around with the idea of building TacticSheet just allow you to either add employee(s) to a project or remove employee(s) from a project when they are no longer needed. Which means in case of the above scenarios administrators would find themselves manually remembering (or relying on emails sent by Project Managers) to add and remove resources from a given project.

One of our goals while creating TacticSheet was also to provide a Timesheet System with the Infrastructure that will allow folks integrate TacticSheet with external systems and consume the Timesheet data from multiple other systems.

When I think of a full blown Resource Management System talking to TacticSheet, the whole idea of adding resources to a project for the entire course of the project and not letting the administrator choose for how long an employee would work on a project, sounds fundamentally wrong.

This weekend we ended up addressing this issue and we seem to have solved it rather elegantly.

TacticSheet now offers a separate Project Allocation screen. This screen allows you to add an employee to a project which is what most commercial timesheet entry systems also allow you to do.

The same screen also offers an advanced allocation option - which allows you to pick the exact dates or range of dates for which the employee will be involved with the project. You can add the sample employee to the project multiple times by choosing different start dates and end dates as long as these start dates and end dates don’t overlap for the same employee.

The screen allows you to address all three scenarios I described above using TacticSheet.

The same feature is also going to allow us to give you a lot of other additional kick-ass features in the future. For example, storing this data will allow TacticSheet to look into the future and see how many guys are really busy and for what time durations. Having this data there opens up a new dimension of reporting for us and will let us do some awesome reports primarily on the Resource allocation side in the future.

More features, goodness and posts coming up in the future. We have barely started, and are far from done. Stay tuned for more!

posted on Monday, November 5, 2007 5:39:48 PM UTC by Rajiv Popat  #    Comments [0]
Posted on: Wednesday, October 31, 2007 by Rajiv Popat

TacticSheet New Features - Announcement 1

A few days ago we completed building the basic framework of TacticSheet, uploaded a development sprint of TacticSheet and announced it live. TacticSheet is an Open Source Timesheet and ExpenseSheet System built on .NET 3.5, C# 3.0, LINQ and Oracas Beta 2. If you haven’t heard of TacticSheet or want to learn more about it, click here.

This weekend I worked on a couple of other enhancements to make this product much more usable in the long run. Some of the features completed this weekend include:


Support for Timesheet Audit Trails

Respecting the iron triangle plays a vital role in any software project. But when you are only giving time to a project only during free time, weekends and holidays this prioritizing becomes vital. Audit trails for timesheets was on my mind when I played around with the basic idea of building TacticSheet. Dropping it out of the first sprint I uploaded on source-forge, was purely a matter of respecting the iron triangle and realizing that I lacked time.

I found some time this weekend and this was one of the important features that I really wanted TacticSheet to have - So obviously it made it into TacticSheet. Today, you can see audit trails at timesheet level right on the same screen where you are filing your time using TacticSheet. We decided to draw inspiration from most commercial time-sheet entry systems out there and call our timesheet based audit trails "Timesheet History".

For audit-trail purposes we also go ahead and catch data at each timesheet line item level, but these audit trails are not shown anywhere on the TacticSheet screens because we don’t see these adding a lot of value for most organizations. Given the stage where TacticSheet stands today, we need to focus on other important features before we get carried away with making audit trails better.

We still store the trails on a line item level and keep them there because we want TacticSheet to adhere to general auditing principal - delete nothing. In future, as the application grows, this is expected to allow us to provide screens which will provide detailed audit trails and deeper insight into what happens inside each timesheet every time it changes state.

Our Database is Now Scripted and under SVN

We’ve gone ahead and brought out database under SVN by scripting it out to a proper database project. Now you can have the database created by running a command file located under the database project which is included in the code base.

Running this single command file will have TacticSheet create the database schema and all sample data needed to get the application up and running. Once the file runs successfully, change your web.config connection-string to the right database. Once done, you can launch TacticSheet and login using default credentials (username: admin password: admin).

Setting up the development environment of TacticSheet is now stupid simple! So there’s no reason why you shouldn’t try it out. Go ahead, grab the latest copy of the code from our SVN and give it a dry run. Drop me an email and let me know what you think.

Employees should not be able to Un-submit Approved Timesheets

After I announced TacticSheet live I received a few emails from folks encouraging me, congratulating me and wishing me good luck. I also got a couple of feedbacks from guys who are not into .NET, but work with a lot with timesheets. Some of these feedbacks were fairly valuable. For example, one of the observation that was made was:

“Employees should not be allowed to un-submit timesheets which have already been approved”

I looked at this one with a little bit of skepticism. So if an employee makes a mistake, how does he fix it? After a little bit of communication back and forth the person who had requested the feature explained:

  1. A normal user is allowed to un-submit timesheets which have been submitted by him till they are approved.
  2. Once approved, the user should not be allowed to un-submit the approved timesheets.
  3. The administrators however, can un-submit even approved timesheets on behalf of the user so that the user can go ahead and fix his mistakes.
  4. Once un-submitted by an administrator, the user will need to re-file that timesheet and the timesheet will have to go through approval process all over again.
  5. No approved timesheets can be deleted. Not even by the administrator. Administrators can un-submit the timesheet which have been approved.
  6. Once un-submitted the timesheet can then be deleted by the employee himself.
  7. All of this is audit trailed so there is no confusion.

In general the above rules made a lot of sense and are now a part of TacticSheet.

We have more features, goodness and posts coming up! Stay Tuned!

To stay informed about TacticSheet new features you can sign-up to the TacticSheet Mailing List. If you are an enthusiastic .NET developer and want to stay informed about the technical changes we’re making to TacticSheet signup for the Developer Mailing List. We have barely started, and are far from done. Stay tuned for more!

posted on Wednesday, October 31, 2007 10:36:17 AM UTC by Rajiv Popat  #    Comments [0]
Posted on: Thursday, October 25, 2007 by Rajiv Popat

TacticSheet - Open Source TimeSheet and ExpenseSheet System Built On .NET 3.5

Last couple of weekends, I started work on an Open Source Timesheet Entry System using .NET 3.5, C# 3.0 and ASP.NET, which, for no particular reason, was named TacticSheet.

In the coming months (depending on the number of free weekends I get :)) TacticSheet will have its own domain domain name, a full blown website and a steady open source life cycle but for now that I seemed to have reached a logical point where I can at-least see the basic functionality of the application taking shape. I could hardly resist the temptation of sharing TacticSheet with fellow developers and my blog readers.

If you care, here’s a quick FAQ of TacticSheet (or a list of few questions that might be going through your head right now as you read this :)):

What is TacticSheet?

It’s a Free and Open Source Timesheet Entry System which in the long run is supposed to provide the the ability to do Timesheets and Expense-sheets within an enterprise.

Can I Use TacticSheet in My Organization Today?

No. It’s far from being production ready yet. It has the basic framework which will allow people to file timesheets and project managers and line managers to approve or reject timesheets. As of Today TacticSheet is not fully stable, not fully tested and may have a lot of breaking changes in the next months as it moves towards a Release 1. Some of the very important features that most organizations would need e.g. Audit trails, email notifications etc. are currently missing. To make things worse, even our database isn’t scripted yet. :)

In the coming couple of months we’ll be working to get these issues ironed out so that you can start using TacticSheet in your organization and upgrade safely to a new version every time a new version comes out. Till then, feel free to play around with TacticSheet Development builds, but please don’t deploy them to production environments.

If it’s not fully ready why are you announcing it live?

Because good software is never complete. :) On a serious note, I’m interested in getting some feedback and contributions from the community, fellow developers and above all - you dear reader! Go to our Source-Forge Home Page, grab the source code from our SVN (or Browse our online SVN), try it out, drop a comment or email and let me know what you think about the application!

We don’t have a lot of documentation on setting up the development environment but we're hoping most folks will find it very straight forward. If you want help setting it up, please drop question(s) in the Product Forum and we’ll be happy to answer them.

If you think you’ve found a bug, please file it here.

Feel like contributing? Read on!

How Can I Contribute?

We’re looking for a few one-man-armies who are thick skinned developers and people who are into shipping good software (not just writing documents and following crazy process!). We really think the world could use one more Timesheet entry system built on .NET, especially if it’s free and open source! Do you?

Besides kick ass developers, we are also looking for UI folks and people who can test the application inside out! Interested?

If you fall in any of the above categories, are fortunate enough to find some free time during weekends and crazy enough to write code during that free time, Email me using the “mail” icon on the left panel of this page and we can discuss how you can contribute.

You can also contribute by Submitting SVN Patches, filing bugs or just participating in the forums.

What’s the Technology Stack?

We’re starting out with .NET 3.5 and Beta 2 Release of Orcas. Of course whenever Orcas RTMs, (end of this year / next year), we will be working to ensure that TacticSheet migrates over to and works with the RTM version. For the enthusiastic and passionate .NET developers here’s the technology stack TacticSheet uses:

  1. Orcas Beta 2.
  2. .NET 3.5.
  3. C# 3.0.
  4. LINQ to SQL.
  5. XLINQ.
  6. ASP.NET Ajax and ASP.NET Ajax Toolkit.
  7. SQL Server 2005. (But there’s no Reason why you couldn’t make TacticSheet work in SQL Express!)

How Can I Stay Informed about the Project?

We have 2 different mailing lists – depending on the kind of involvement you want to have to the kind of information you want to stay updated with feel free to join any one of our mailing lists.

  1. The General TacticSheet Mailing group – Users who are interested in staying informed about the new features of TacticSheet can sign up for this mailing group.
  2. The TacticSheet Technology Mailing Group – We will be discussing most new technologies we use in TacticSheet here whenever we decide to use a new technology. We will also be discussing the design and technical changes that TacticSheet undergoes in the future in this mailing group.

When will TacticSheet Development Complete?

As of now, I don’t think I’ll ever be ‘done’ with this project, which is the whole point! I’m a firm believer of supporting everything I write. I intend on extending and supporting TacticSheet for years to come. Watch out for a lot of new features and version, year after year!

Why are we writing TacticSheet?

This calls for a long post, but for now let’s just say - Because, we can. (You can expect another detailed post on this topic in the near future :))

What’s the TacticSheet License?

The product is currently under GPL. Also, we do not allow or encourage forks of TacticSheet for the time being. I personally feel that the product is too premature for now and forking will add to confusion. As the product grows we plan on moving to a much more liberal license like FreeBSD.

Even though the license is strictly GPL we are fairly liberal towards the use of TacticSheet – it’s primarily written for a hobby and not with an intent of making money – so if you want to do something crazy with the code-base please email me and we’ll see to it that you can do whatever you are trying to do without being charged or sued :).

So, now that TacticSheet has finally been born, wish us luck and growth! Stay tuned for more posts, features and goodness.

posted on Thursday, October 25, 2007 6:30:46 PM UTC by Rajiv Popat  #    Comments [4]