Pragmatic vs Theoretical Development Practices
I tell a story about my very first assigned development task to my development friends because it really sets the development practice tone of reality to me. The first day I was on my first job after graduate school I was given a simple task of creating several reports for a plant manager to review over his morning cup of coffee. I really do not remember the content of those reports, but I do remember Sybase, Stored Procedures and PowerBuilder (I do not do Sybase, PowerBuilder or reports anymore). It was actually a pretty simple task to complete and a good starter project to get my feet wet in the new corporate culture I had entered.
I hit the ground running and knocked out a solution for the plant manager in 2 weeks (10 business days). He was really excited to finally have this information available anytime he wanted. He was currently wading through a lot of printed material the shift managers would leave waiting for him, etc. I was excited because I had pleased my customer (the plant manager) with my first project. I was very proud of myself and was beaming confidence. All I had to do now was get my new reports integrated in the nightly system updates. (play evil music here)
So I filled out the forms (which if I remember correctly took about an hour just to find them all), submitted them and fully expected to have my new reports available to the manager in a few days. Boy was I wrong! A week goes by and I get a phone call telling me that I needed to have three code reviews (DBA, Stored Procedures and PowerBuilder). I did not even know what a code review was! I am a self taught developer and had degrees in Polymer Chemistry and Textile Engineering (I was in a textile company by the way) and had done a lot of development all by myself. So I said, fine, when and where.
I was ripped all over the place in the first code review (PowerBuilder), it was brutal. The other two reviews were just as bad. I then had 7 inches of 3 ring binders containing PowerBuilder coding standards promptly dropped on my desk. Then came the SQL coding standards and a bloody introduction to an extremely hard to use CASE tool. I really could not believe what I was being hit with, why did they not even tell me this in the first week? I still have no clue.
Looking back having a peer code review is not a bad thing. I am still very independent and plan on staying that way. I try to remain consistent in my coding practices, hence Code Smith and other code gen techniques. But in reality technology changes rapidly and a pattern or technique that is great today, is out dated in a few months. But I do like to share code with peers and get feedback, I do want to be the best I can after all.
The CASE tool on the other hand was bad and I still think pretty useless. I saw it as only adding a great deal of impedance to a simple task. The company had thousands upon thousands of custom data types. This means there were literally hundreds of data types that were nothing more than an integer with a new name. Of course I had to pick the right one and hope I was not wrong, etc. The CASE tool itself was very complicated and I could easily have 20-30 individual windows open at once.
Ultimately the task I satisfied the paying client with in 2 weeks took another 6 months to get deployed. By that time the manager had solved his problem another way and even forgot I had created the reports for him. Ultimately they were never used, which to me is the ultimate insult to a developer. It also wasted several thousand of the company’s dollars (I spent about 2/3 of my time on this project for 6 months remember). The code review did not change the operation of the application. It did help me code more inline with the company’s standards and be more organized with my coding. The CASE/SQL side of things was just atrociously unneeded. Overall the extra 26 weeks of work it took to solve the problem was unneeded and a complete waste of money. This is why I know many business units try their best to keep the IT department from knowing about software solutions they create. Hence the large number of rouge Access applications sitting on assistant’s and manager’s computers. This will always be the case.
I consider myself a very pragmatic developer. I make mistakes, everyone does. Most of my biggest mistakes come from putting energy into trying to abide by theoretical development guidelines. I see them all the time, their practitioners are loud, but a minority. A recent Blog I read talks about the CSS layout zealots and how their arguments are impractical. I have to agree with the points made. I am gong to use this example because it is recent and serves my point well. I have spent a lot of time the last year getting comfortable with CSS layout techniques. While I am getting comfortable with them, it takes so much longer to get a layout done in CSS than just using a table that it is almost to expensive to use CSS. I do see it as a partial ‘job security’ route to take. There are benefits, no doubt, but they are so expensive in comparison more often than not. I do not know about you, but my experience has proven out that clients want something they can touch as fast as possible and table layouts get you there in a minute or two, whereas a CSS layout may take a few days or weeks to accomplish the same thing. Clients want to pay less, not more, again Tables win, sorry. Getting a site online sooner typically means the client makes money sooner and they pay you sooner (both good). At this point getting a 100% CSS layout done is a secondary choice for me. Getting the application up is much more important. Updating the CSS features can be done after the site is up and creating revenue.
There are many more examples to point out in today’s software development climate. Yes, I have heard the spending a day writing a unit test for a function can save you 5 days of work a year later ad nauseum. I don’t buy it. Get It Done Today gets you money tomorrow. Upgrading next week and the week after is just fine. You are going to be applying upgrades and changes throughout the life of the application anyway. This is why you should take notes as you work. Write down things you want to come back to, Visual Studio has a nice TODO feature in it. Other tools like TFS and OnTime also are great for listing tasks.
The bottom line you should always remember: The Client could care less what technology you use to solve their problem. They just want their problem solved today. So solve it as quickly as you can, minimize the introduction of new problems and use continuous improvement to make the solution better over time.