In May this year, I was asked to take over as tech-lead on a project at the company I’m contracted out to. The current tech-lead resigned and decided to move on to greener pastures.
What I discovered when I took over the reigns was a little unnerving…
The solution is more than 5 years old, and it has been through many technology overhauls, from classic ASP, to ASP.NET 1.0, 1.1 and is now running in 2.0
However, this hasn’t been a clean transition, with a lot of the code still being in classic ASP, as well as ASP.NET 1.1 (syntactically, using deprecated methods etc.).
There are no clean separations of tiers. All of the business logic either resides either in the front-end (GUI), or in SQL stored procedures and ad-hoc queries. The sub-projects that do exist (for database calls) have namespace and class names like db, c, m and wc… (I’m still trying to figure it out myself)
But, it’s not all doom and gloom. The technology may be a hinderance, but what makes this all bearable is the team. The guys are a tightly-knit team that never fail to deliver, even at the cost of overtime and working weekends. They care about the solution, even though they couldn’t get it to compile.
That’s where I come in.
A little work had to be done on the team dynamic, but mostly the code needed a lot of attention. Over the last few weeks, I’ve been stepping through the code, page by page, trying to get it to compile and reach some sort of stabilisation point. Once I had reached that point, I put the solution into a newly created TFS branch which will be the base for all development going forward.
Then, I put it into CruiseControl.net, so we can get red/green light notifications on how healthy our new branch is, upon every check-in.
This has been a lesson in software development evolution for the team, as they were silo’d in the way they approached software development before. They’re very excited about this, as they now have a computer to tell them when something is broken, instead of patching software as they were doing before, hoping for the best, and discovering bugs way down the software delivery line.
The tasks following this primary but essential step will be applying unit tests retrospectively to the existing code base, and upgrading the legacy code in the classic ASP pages and the 1.x ASP.NET pages to at least ASP.NET 2.0, if not 3.5.
So far, it has been an interesting challenge, and I’m confident only good can come from this. The team are new to proper source control procedures, continuous integration and unit testing. Showing them the why’s and how’s, along with separating business logic out of presentation tier into their own contained, testable tiers is something I’m really looking forward to.
There’s no better reward than seeing the light bulb above their heads switch on as they suddenly realise that software development can not only be easier, but fun too.