The Efficient Coder

Sitting out the Great Quality Wars of '09

kevinw@software-logistics.com (Kevin D. Wolf) — Thu, 12 Feb 2009 17:44:54 GMT

Lines are starting to get drawn for the Great Quality Wars of '09. On one side you have camp led by Joel Spolsky and the now infamous Stack Overflow Podcast #38, and the other camp led by Uncle Bob. I'm sitting this one out, from what I can see so far, both sides are going to get bloodied up where the discussion turns from a reasonable and positive debate to personal attacks. We have a lot of problems in our industry and dividing it into factions won't help anyone. Especially when I see this religious war based on how do I get there, not where do we want to go.

This, being on a much greater scale, reminds me of the Great Coding Convention Battles I participated in within a company in the early 90's. One of the stupidest things we discussed over the course of a month of meetings was whether to use the following syntax for one line after an if statement.

if(true)
DoSomething();

if(true)
{
DoSomething();
}

Looking back this was a tremendous waste of time, albeit a relatively fun discussion in our meetings where both sides decided the other side was a bunch of hacks.

I was in the

if(true)
DoSomething()

camp unless I wasn't.

For the case of:

if(true)
while(someCondition)
DoSomethingElse();

I would use the convention:

if(true)
{
while(someCondition)
DoSomethingElse();
}

where I would be in both camps. What does this mean? Does this mean I'm a moderate? Well no, I do have very strong views on both coding (and politics but I'll spare you the pain on discussing my political views here). I think the main reason I had strong feelings on my approach was that the other camp wasn't using C/C++ in their day to day work and kept bringing up examples and what *experts* said about the topic and under no circumstance should we have a block of code not enclosed in curly brackets. My camp lived in a C/C++ editor for most of our work.

Do I agree with the statement that Quality doesn't matter? No. Do I agree with the statement that Quality is the most important thing? No. For any system there is really only one true measurement of success:

In the long term is your user community satisfied and will they continue to use your software to enhance their business or personal lives.

Anything else is pure rubbish. You may have a very high quality system that is just a joy to maintain, but unless people use your software, you probably won't (and shouldn't) get past V1.0. You also could have a system that you deploy within a month or two that people just love, but it has tons of bugs in the core architecture and can't be maintained, you probably won't get beyond V1.0 either.

Quality is an important attribute of your system, however quality is not free. Building a quality systems is not ensured by a set of tools, techniques or processes. Quality is a result of an individual's commitment and a culture within your organization.

There is a danger on both ends of the spectrum. On one end of the spectrum there is "we don't need these new fangled tools and techniques, our Cobol and Assembly Language application runs just fine", yeah right, there's a real competitive edge. I'm probably not going to buy or use your software, and if I do, I'm probably not going to apply any updates unless absolutely necessary. On the other end of the spectrum, we try to rigorously follow the latest fads something like not writing a single line of code without a test, attempting to achieve 100% code coverage, or program exclusively against interfaces. While this does sound good in reality are you putting too much trust in your metrics? Code coverage of 100% (or even 90%) means your code was run, that's it. I may be different, but I know most of my bugs are edge conditions I don't account for even if I do have a test suite covering that chunk of code. The code coverage metric does little to protect me against these problems.

What is the middle ground here? It's actually pretty simple, think for yourself, make sure you write lots code that makes it into production, it doesn't do much good to get your code to a certain point and gloss over all the little details. Also read as much as possible.

Although I think the SOLID Principles offer a number of good concepts, I personally don't agree with all those concepts. You may agree with all those concepts. That's OK. One area I disagree with is the Single Responsibility Principle or SRP. I've seen implementations of this in code a code base I needed to extend, and it's just not my cup-of-tea, too much noise, classes are not free. The developer swore by this technique. That's OK.

I wish I could find the transcript, but let me paraphrase a discussion of SRP from Uncle Bob's Hanselminutes interview (right around 3 inutes into the podcast)

Uncle Bob: This is somewhat out of the norm for object oriented design. Early Object Oriented Design Principals had us grouping together functions of that operated on the same data structures so that the methods of the class manipulate the same variables.

Scott: That definitely flips things on its head.

Early on I learned one of the core principals of Object Oriented Analysis and Design is it's all about the data and methods acting upon that data via encapsulation. Over time your business rules will probably change, however the structure of your data will remain fairly static. The way I design LOB type apps is ruthlessly focus on my physical data model. If you don't get that right, you will be fighting with an impedance mismatch all through your development cycle. Although I could certainly see the value of a different approach, I keep my business objects 1:1 in sync with the database tables. The primary reason for this is simplicity, once you break that relationship you introduce a mapping layer that is sometime necessary but comes at a cost of additional code. The only code you know has zero bugs is code you don't write.

Maybe I'm "old-school" but my process has allowed me to pay the bills for the past 20 years now. In some cases the developers picking up my code said, this is so incredibly easy to maintain and the hand off went smoothly with very few support calls. In other cases, people just said it was a mess. It seemed like people that liked my code have been in the industry 10+ years and have handed over legacy code themselves. The people that thought I was a hack usually had less than 5 years and already knew everything there was about writing software. They were just waiting for their first chance to start from scratch, build a product and show us old-timers how it's done. I suspect, at one time I thought I knew everything about writing code. Maybe this is a right-of-passage?

Using classes to group together functions just doesn't smell right to me, it may to you. That is ok. I have the right to express my opinion just as Joel and Uncle Bob did, neither of these two people are hacks and I don't think I am either. We as an industry need to do a better job of leaving out the religion and personal attacks, software is hard. Period. What works for one person on one project would cause a different person to fail.

Another thing to think about in adopting and evaluating new techniques and technologies is one of the concepts of the Software Capability Maturity Model or CMM. If you are a Level 1 organization, you cannot skip directly to a Level 3 or 4 organization. You must go through Level 2. If you attempt to implement processes found at Level 3 or 4 you will fail.

At any point in your career your toolbox contains a finite number of tools, over time you should be continually adding tools to your tool box or you won't advance in your career. If you attempt to implement something like the SOLID principals before having in place effective requirements gathering, defect tracking, or a continuous integration process your time would be much better spent focusing on blocking and tackling exercises rather than more advanced techniques. It's surprising how many organizations I've worked with that try to adopt the latest advanced technique, but their bug tracking is emails, source control is sorely lacking and requirements gathering consists of meetings where the main goal is for people to hear themselves talk and sound important! I've seen many more projects fail because of the lack of effective leadership, poor requirements or project management than I have because the programmers used the wrong technique or pattern. Before we put stealth on our airplane, let's make sure our airplanes fly.

Over time there have a been considerable advances in our field of software engineering, some stick around some don't. Are we still using those old Rational Rose Puffy Clouds. I liked my Puffy Clouds! I want my Puffy Clouds back! None of these should be considered 100% bad and ignored, learn something from these, but don't just jump in and blindly implement without thinking. Put what works for you in your tool box, have a full tool box and select the exact right tool to solve your problem and more importantly, know why you picked that tool.

I'm looking forward to the "smack-down" between Joel and Uncle Bob in an upcoming Stack Overflow episode! Would be very interesting to see them on UFC as well. In the mean time, I'm going to keep writing software, reading blogs and keep adding more tools to my tool box.

-ec

It's a Great Time to be a Developer

kevinw@software-logistics.com (Kevin D. Wolf) — Fri, 06 Feb 2009 15:39:35 GMT

With all the grim economic news, there has never been a better time to be a developer (well maybe during the internet bubble, but that wasn't sustainable). As an independent consultant, I'm always just a little worried about what the next six months will bring. I've been doing this for about 8 years now and so far there has been no shortage of work, but you never know what the future will hold. I think 2009 may provide a different way of thinking about how I perform my craft to pay the bills, let me explain. When doing client work there is really no long term guarantee. It's a process of identifying a need for their organization, doing an excellent job filling that need, get a check, rinse and repeat. You are really establishing a "dependency" on your client, their needs and cash flow have a big influence on your future. As a developer we know that in most cases dependencies are not a good thing.

That's where I think there are some great opportunities these days for us developers to break these dependencies and really take control of our future. As much as I enjoying developing systems to make my clients succeed, I would rather develop systems to make myself succeed! How is this possible?
Well I'm pursuing two opportunities right now that you can too! The costs and barriers for entry are negligible.

The first one is really sort of fun, I'm building a game for XBox Community Games. The idea is I build software, publish it, and it becomes available to millions of XBox users to download and play for a very small fee where a large portion of that goes into my account. This means if I can make the game interesting enough to tap into an extremely small percentage of the millions of users, the income may not be all that trivial. I'm not buying that 54 foot yacht yet, but who knows. The point here is that I have a high level of control over the success and outcome of this effort, the advertising and sales are taken care of via the Community Games site. I can focus on cuttin' code and not have to build a business with dozens of employees and all the headaches that come with that.

I think the next opportunity is even more exciting and beginning the second half of this year will merit a considerable investment in my time. I'm already getting my feet wet with this technology and I'm excited for the RTM date. This approach and techonology changes things, period. Over the past eight years, I've been working on a product I call The Chaos Filter. I've spun off a few little products that generate some revenue, but really haven't cranked up the marketing engine yet. My thought is once I do this, my primary role will shift from building and extending the product to building and extending the business to support that product. The challenge has always been, how can I focus on what I enjoy and outsource 95% of everything else yet remain in enough control to be successful. My product is really a set of highly configurable services that work together well. My goal is to allow subject matter experts; non programmers but technical folks; to very quickly customize and assemble those services into things I'm calling MicroApps. These will be built for highly specialized niche markets. My thought is not to sell these for hundreds or thousands of dollars, but a monthly subscription fee that will usually be less than $20. Basically a high value, low cost solution that will be very easy for people to sign up for and keep coming back. To make any money at this effort, I'm going to need a ton of people signing up. That's where I see the Azure Services Platform come in. Without building a large company, I can partner with subject matter experts to build these MicroApps. Then make these products available to the Windows Live user base. This also offers a highly scalable platform that as my product grows and I need more capacity, I'll just need to adjust the number of server instances in a configuration file and wha-la I'm more scalable. Again, as with the XBox game, I can focus on my core competency, cuttin' code.

Another awesome opportunity would be to start writing applications for the iPhone and iPod Touch. Although being a .NET developer, I'll probably focus on the two opportunities I've outlined above, however this once can't be ignored. Apple did a great job of making it super simple for people to trade you their money for your apps. I purchased a MacBook and have started to learn Objective C. Even though this seems very appealing, I just don't see spending my valuable time on this anytime soon. I guess the XBox and Azure Live Services just turn out to be a fad *cough* there are other opportunities out there.

I'm spending about two thirds of my time doing client work and the other third trying to figure out what type of killer app I'm going to develop that will allow me to spend all my time programming for fun, not necessarily to pay the bills. This approach isn't for everyone, if you enjoy the security of working for a company and thrill of being part of a high performance team you may have found your niche, if not, maybe it's time to start looking at what you can do on your own.

-ec