Solving bugs or working on maintainability

Last friday I had a discussion with one of my collegues who is one of the guys who's responsible for setting up the entire project. He seems to be a nice guy with reasonable knowledge about some stuff. He's been working on the project for probably years now so he seems to be a bit of an authorithy within the project.

The discussion i had was about the importance of solving small bugs vs. setting up a build script which doesn't exist yet. While he very much agreed to the idea that a build script would be very nice to have ( he brought the idea up several times himself ), he was clearly on the side of giving preference to solve bugs first because this would be something the client would notice and would directly improve customer satisfaction while a build script would be something a client would notice nothing about ( at least not diretly ).

Because there should have been a release last week everybody in my team stressed on solving as much bugs as possible.

While i know that solving bugs is at some degree important i think maintainability should also be a requirement with a pretty high priority in projects. Because of his status in the project and his opinions on solving bugs vs. working on maintainability I suggested to work for 90% of the time on solving bugs and 10% of the time on maintainability ( first step would be a build script  ). I couldn't get him to agree on this but he finally agreed to give me some time after this release would be released which is in the beginnng of this week.

My ideas about steps to take to improve maintainability are the following:

• Setup a build script which does a complete build of all the solutions in a single step
  
• Make sure the build script runs as part of a continues integration server in Team Foundation System
  
• Add Smoke Tests and Mock Client Tests using Watin and add them to the continues build process

I've pointed out my ideas several times and i dont want to whine to much about the situation since i'm still new in this team and i also don't want to make people feel offended when i'm constantly criticising their views about the development process and what should be done etc etc. Therefore i decided to agree with him on solving bugs for now and starting to work on the steps i mentioned above after the current release is done. While i'm feeling stupid solving unimportant bugs while there isn't even a build script yet I think i have to sacrifice a bit to make sure my relation with the people in the team will stay healthy.

Next week i will start making sure at least the first 2 steps, (buidscript and continues build) will be fixed and i will also probably talk to the test teamlead about making some automated Smoke Tests and Mock Client tests which should serve as the first regression / functional tests which will be added to the continues build. The test teamlead at least told me that he found that testing isn't considered to be as important as he thought it should be so at least i got someone in the testteam on my side which im pretty happy about.

To be continued next week...

About this blog

In this blog i will talk about what kind of things i'm doing at my work.

About me:

I work as a .Net software engineer at a big ICT company in the netherlands. I've been a software engineer for about 6 years now but i've started programming years before that. Basically i started out writing a website using perl with a textfile database. I became so into programming that i switched studies from doing a electrical engineering study first to doinh an ICT study. Basically you can say that i've made my work out of my hobby.

When i first began to work i started out with a parttime job next to my new study where i was programming in asp and MSSQL 7.0. After a while the company i worked for at the time made the transition to .Net using VB.Net. Also a few java projects came up every once in a while. One of the more interesting projects back then was a javaproject using struts as an application framework. That's also when i became very much interested in design patterns and ways to make the practice of software engineering better.

Later ( about 2 years ago ) i switched companies to be able to work for a much bigger company doing bigger projects and having much more experienced people i could learn from. One of the things i discovered pretty quicky was that the amount of skills i allready had learned were pretty good compared to the skills i saw people had at the projects i started working for.

When i began working at the new company i started to get very interested in doing projects in an agile manner, at first by setting up a continues integration server and making some unit tests and right now by taking a look at the complete software engineering process and adopting as much of the agile processes as i can convince my teammembers to do.

Probably a lot of what I will talk about on this blog will be about me trying to make projects work in an agile fashion. I unfortunately haven't worked in projects with a complete agile process but i keep trying to convince people around me to adapt agile practices with mixed succes.
Since a month ago I joined a project involving a big sytem involving mortgages with a big team consisting of testers, designers, developers and implementers. They work somewhat iterative but there are alot of things which can be done much more agile.

In the coming posts i will start explaining the steps i'm taking to slowly transition to agile. Hopefully i will succeed in this effort.

IvoG