XanderLand

As I posted awhile back, I've been working occasionally on modifying the ASP.Net IssueTracker Starter Kit, and I thought that I'd blog about about how I start on a project like this.

The first thing that I did, was to load it up in Visual Studio, and commit the whole thing to source control.  Now I had a point that I could get back to, regardless of how badly I screwed anything up.  Then, I set out to get an idea about the structure, not by looking at code, but by poking around and looking at how the projects fit together, what referenced what, and getting an overview of what files where where and so forth.  Once I had a good idea of how the application fit together, I tore it apart.  I added projects, renamed the assemblies and changed the entire namespace structure to fit with my standard naming conventions.  I moved code from one assembly to another and in the end, just generally caused as much choas as I felt the compiler could handle without expensive psychiatric counseling.  I attempted to build the solution, and watched bemusedly as the compiler spat out error after error, right back at me.  Then, one by one, I fixed every one of the errors, which required me to touch nearly every file in the entire solution.  For the next step, I set my sights on the database.  Every object in the IssueTracker database is created by a script called, who would have guessed, CreateDatabaseObjects.sql.  It was a little over three thousand lines long when I started and it had been generated by SQL Server's Enterprise Manager, by the look of it.  The formatting was iffy, (as SQL Server generated scripts tend to be) and so I sat down with that sucker, and re-formatted the entire thing.  I reworked every single line, from first to last, so that it was uniform and conformed to the formatting standards that I use when I write SQL by hand.

"Why?" you ask?  "Why Xander, would you spend hours rearranging code, and re-formatting SQL statements?  Does it really make the application better?  Does it make enough of a difference in the performance, or the code to be worth it?"

The answer is no.  The answer is no, because you'd be asking the wrong questions, and making the wrong presumptions about my goals in this exercise.  Did I make the application better?  Yes, I think that I did, at least a bit.  For instance, I think that the logical tiers are better seperated now that I've teased apart the UI and business layers.  Not better enough to be worth the time that I spent, however.  What was really invaluable to me, was having to touch every last piece of the application.  Having to recreate connections between the classes that had been broken, having to reformat the DDL for every column in every table, having to look at and toy with every single stored procedure...This is where the value was.  I can *always* get a concept of the application by poking around.  Looking at code, picking through tables and sprocs with Enterprise Manager...These things will teach me bits about the app.  I can't *know* it, however, until I've worked with it, and worked with it all.  Touching every file, every single database object, these are the things that I do that make this application mine, to start me down the path of knowledge that I need in order to work with this application and mold it into what I want it to be.  These are the things that I do in order to establish an ownership, so that the code that I write won't stand out like a slapped-on patch, but will fit with the structure and the vision of the application as if it were always there. This is a prerequisite for me, because only if I have this sense of ownership can I feel that I'm writing code that truly integrates.