What went wrong

I’m writing up how the planning went wrong in our last sprint, because I find it interesting thinking about how it actually went wrong, and what I can do to prevent the same sort of issues in the next sprint.

First off, here’s what our software is supposed to do:

  • It integrates into a (payment) system developed by a third party.
  • Within the framework as defined by others, the main method in the component receives a parameter, which contains information that can be used to get the file name of a file exported by their system.
  • The file is in their common format (XML) and represents a batch of debit orders to be sent to the bank, which our code must then transform into a flat file that conforms to the bank’s format. (This is an over-simplification but is good enough for this blog.)
  • The third party kindly gave us a (StreamReader-derived) component that reads their file into strongly typed transactions via a GetNextTransaction method.
  • I undertook to do the development of transforming the transactions to the flat file format.
  • I was aware that the file also required writing one or more headers and one or more footers, but I wanted to take a step back and not be solely responsible for all the functional code this time around, so…
  • I tasked our companion (who is no longer with us, pending the result of his performance hearing) with the header.
  • No task was created for the footers. Oops.
  • No task was created for the “contra” lines, which are summary lines. Oops again.

My task planning was done solely from the point of view of the transactions.

The other developer wrote pretty patterns, a class factory to determine what to do when which bank is involved, and so on. He also didn’t notice that a bunch of things were not catered for in the development.

Lester (the departed developer) didn’t really do anything at all. Well… he did do one thing sort of… The reader component given to us gave access to the file header, also as a strong type. Our dim-witted friend saved that header into a local variable, which he then did not use. (i.e. He didn’t even write anything to the output file. He just saved a reference to something we already had into an unnecessary variable, which then immediately went out of scope. Fucking brilliant.)

Maybe if dumb-ass had done something more, he could have noticed that there was also a second header to be considered, and brought it to somebody’s attention. And maybe then we could have realized that there also two footers and the contra lines. But that didn’t happen.

What did happen was, as mentioned last time, I then did all the functional code myself while the rest of the team slept, and then the whole team had to work late into the night to test that code and fix the bugs, but at least we made it, barely.

I take responsibility for this… I mean, I did not read the fucking manual.

My typing of this entry was just interrupted by our sprint retrospective, and I thus raised RTFM as one of the “What we can do better” issues. Everyone mostly agreed on what I wrote here otherwise… except that they didn’t blame me alone for the issues. Anyway, our major stumbling blocks thus far have been mostly our insufficient pre-planning and then also planning itself.

The main user story for the next sprint is more or less the reverse of what we did this last sprint. (Convert a file that comes back from the bank into the XML format and pull into payment system, which then does what it needs to do, like update subscriber account details, and reverse presumed payments made in the event of failed debit orders.) The main difference this way around is that we don’t have a “reader” for the file; this time I am writing it (I started the prototyping already) and will make sure it does a thorough job, leaving out nothing of the specification. Prototyping it and discussing it with my colleague should ensure that the planning is not lacking this time. (And most importantly for me, though it has nothing to do with the point of this post, is that in this relatively simple project, I get to write the code that is more interesting, leaving the simpler task of writing out the transformed file, and the syntactic sugar of creating pretty code patterns, to my colleague.)

Advertisements

About Jerome

I am a senior C# developer in Johannesburg, South Africa. I am also a recovering addict, who spent nearly eight years using methamphetamine. I write on my recovery blog about my lessons learned and sometimes give advice to others who have made similar mistakes, often from my viewpoint as an atheist, and I also write some C# programming articles on my programming blog.
This entry was posted in Programming and tagged , . Bookmark the permalink.

2 Responses to What went wrong

  1. Cindy says:

    Wow, Lester sounds like a pleasure to work with :-/

    It sounds like you have a lot of experience and knowledge around the work that’s getting done but that you’re getting stuck with the lion share of development work and responsibility. Have you tried using peer programming or peer reviews to help transfer some of your knowledge and help your fellow developers to help you? 🙂

    Like

    • Jerome says:

      Lester will not be missed. In the end, it was our scrum master who actioned his performance hearing… I forgot to mention his endless bullshit tasks in TFS… investigations that never led to any implementations. he was too stupid to know that his work history could be extracted as well… his only check ins were useless changes to references, but he also earned some “code churn” by checking in files, then deleting them several days later. Plus he interrupted every technical meeting by asking stupid questions; sometimes he even took over and then proceeded to display his amazing lack of understanding of ANYTHING as he wrote on the white board.

      Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s