Quality Time

In case you didn’t know, there has been a round of squabbling going because of Joel Spolsky’s post on Duct Tape Programmers. Robert C. Martin (Uncle Bob) has a good response that argues against shipping low quality code. Everyone else is trying to make this into a dichotomy, though it simply feels like one individual puts more priority on release date, while the later puts more priority on code professionalism. Maybe it is because of the recession, but both could be happy if we could just throw more resources at it, in theory.

The age old idiom, show the above triangle, agree that Quality should be high, while Cost and Time should be low. Then you say, “I know all three are desired, but please only pick two”. Money must be limited on most projects these days, reducing the question to priority on Quality or Time?

Since Uncle Bob is a huge proponent of TDD, his main focus for quality is surrounding unit testing, while Joel is focused on individuals that can make nearly anything “work” quickly. Joel shrugs off unit testing as a lofty goal for academics and Uncle Bob focuses more on the common ground between the two and agreeing simplicity should be favored.

Personally, I see the relationship as follows.

Shipping Late > Shipping Shit > Not Shipping

Not shipping or not writing a hack or two to get the product out the door is your worst option. If the product doesn’t go live, all your effort is for nothing. However, hacking the entire thing out the door because proper design and testing takes too much “Time” is only going to paint you into a corner. Sure you will ship something faster than your competitors and maybe that is all your care about. You must consider some important things before saying all that matters is time. Will your customers want to use it? Probably not. Will the developers want to maintain and enhance it? Probably not.

Clearly Time and Quality are important, otherwise they wouldn’t be on the triangle. The key is to balance them appropriately, which is what most individuals are saying. Zealous animosity against or for unit testing aside, the entire argument is subjective. Consider what your demands are and plan appropriately.

Unicode Transformation Format

Had another one of those days yesterday where you get deep in discussion about some of the nitty gritty. This time it was surrounding Unicode and though I knew some pieces of the picture, I could have certainly done with more information.

First and foremost, Unicode is a way of encoding characters as a sequence of bytes. In this case, characters (and even more so strings) are an abstraction. UTF-8/16/32 define different encoding schemes that we can use for those bytes. Each of those bytes are being represented by one hexidecimal value.

source

Looking at the UTF-8/16/32 section of the diagram, we see the different byte representations of the three characters. Also notice that UTF-8 byte representation of 'A' is identical to ASCII. This is true for a large set of the Latin alphabet and ties into why UTF-8, in Latin languages, is usually the most compact Unicode encoding choice. For this reason, storage and data exchange systems prefer it.

C# for example uses UTF-16 encoding for strings, but will default to UTF-8 for streams. UTF-8 isn’t all good though and it should be noted that UTF-8 is significantly more complex to process than UTF-16 because lead bytes have a relatively complex encoding and up to three trail bytes must be counted. This is due to the fact that Unicode is optimized for 16 bits.

If this interests you, the below documents provide even more insightful information.

Unicode Technical Notes

Unicode is not UTF-\d{1,2}

Python Document on Unicode

Object-Oriented Design Metrics

I have had many discussions with colleagues and friends about the different things we value in software. Why we favor one thing over another, why we implement something a particular way, etc… However, I have also had numerous discussions with developers whose values differed drastically to my own. Arguably, many of these values can be subjective, and when we both reached that conclusion the argument became simply an expression of what we favor and why.

For example, how can you argue the value of something like the single responsibility principle [pdf]? Ask them if they agree and call them an idiot if they say no? Ad hominem has hardly proven to be an effective argument technique. So what do you do to effectively introduce new ideas and argue their value when the other party just keeps asking why that has value?

The technique that has worked for me, in discovering why someone feels a certain way about a principle, is to break everything down to very basic parts that are nearly universally true and introduce your idea under those truths, explaining how it affects them positively. These pieces must be so small that to challenge them would signal the warning signs that the individual is ignorant of the subject matter or intentionally breaking it. In the case of the later, this gives you an ideal platform to challenge why the decision was made and why it is or is not valid. This is more than saying SRP is good because it improves code quality. You must get to the heart of everything, including code quality. And this is where I wish to begin, with OOD metrics that I feel are universally true.

The measure of quality software is more than simply achieving the list of requirements on a specification document. The design of the software itself is equally, if not more so, paramount to the overall quality of the software. In order to properly design complex systems we must have metrics by which to judge that design. These metrics should be so fundamental that they appear to be common sense.

Robustness

Every good programmer wants to produce software that is correct, which means that the program produces the right output for all the anticipated inputs in the program’s application. In addition, we want software to be robust, that is, capable of handling unexpected inputs that are not explicitly defined for its application. For example, if a program is expecting a positive integer and instead is given a negative integer, then the program should be able to recover gracefully from this error. A program that does not gracefully handle such unexpected-input errors is not robust and can be embarrassing for the programmer.

Adaptability

Modern software projects will typically involve large programs that are expected to last for years. Software, therefore, needs to be able to evolve over time in response to changing conditions in its environment. These changes can be expected, such as gradual hardware improvements, or they can be unexpected, such as new requirements. Software should be able to adapt to unexpected events that, in hindsight, really should have been expected. Thus, another important goal of quality software is that it achieves adaptability.

Reusability

Going hand in hand with adaptability is the desire that software be reusable, that code should be usable as a component of different systems in various applications. Developing quality software can be an expensive enterprise, and its cost can be offset somewhat if the software is designed in a way that makes it easily reusable in future applications. Such reuse should be done with care, however, for one of the major sources of software errors can come from inappropriate reuse of software. This means software must also be clear about what it does and does not do. From this clarity, however, software reuse can be a significant cost-saving and time-saving technique.

Technical Debt

Technical Debt is a  metaphor coined by Ward Cunningham. It refers to anything that isn’t done right during development. This includes things like breaking coding rules, introducing potential defects, increasing code complexity, code duplication or even ignoring necessary documentation. We’ve all been through crunch time and when something needs to work and work right NOW, the ends begin to justify the means.

There are quite a few sources describing technical debt, why it is bad, ways around it. There are even applications that try to calculate the actual cost of your technical debt.

It is funny all the ways developers need to “trick” management into appreciating elements of our craft. I cannot remember the last time I spoke to a developer about the monetary cost of using something as fundamental as SOAP vs REST. Yet, here we are, trying to make developers care about the actual value to the company of things with the hope that developers caring about budget and cost will somehow get management caring about the code.

I mean, sometimes technical debt makes sense. Startups are rarely known for their innovative programming improvements and more for their innovative programming. That isn’t to say startups can’t produce elegant code that is a pleasure to work on and easy to enhance. Some probably do, but those that try, likely don’t last long. When you are a startup, money is tight. A few dollars of incurred technical debt today are easily covered by the billions you will be worth in the future...

At least you get to wear a hat afterwards.

The real problem with technical debt,  even for startups, is that most developers are perfectionists.  A study done (link) found that…

87.3% of respondents believe that delivering high quality is more important than delivering on time and on budget.

Not only is that number high, but it was the highest factor when compared with scope, time, staff and money. For me, this says that not only is technical debt bad for the code environment, but it is just as bad to the programmer’s environment and morale.

That is exactly why SCRUM sometimes includes a refactoring backlog to be worked on after releases, as much for improving the code as improving team morale. There are few things more rewarding than slaying dragons. Code dragons that is.

If you want to read more about technical debt, read this article. It really does the best job I have seen analyzing technical debt from both developer/management perspectives, as well as, what is really important about technical debt.

UPDATE: It appears someone else was thinking about technical debt.

Available here.

Too Many Articles

Did you ever want access to over 80 different articles on programming ranging from SRP to code bombs?

Me too!!

link

Predicates

I love predicates. They are a rather recent addition to my toolkit, but already I use them every time I can. What is a predicate you ask?

A predicate is a piece of logic to affirm or deny the subject of a proposition. Programmatically, a predicate is a function that returns true or false when given a class or value. For example.

public bool Contains(IProduct product)

{

    Func<IProduct, bool> predicate = x => x.Name == product.Name;

    foreach (var item in products)

    {

        if (predicate(item))

        {

            return true;

        }

    }

    return false;

}

Pretty cool, but let’s get rid of that foreach.

public bool Contains(IProduct product)

{

    Func<IProduct, bool> predicate = x => x.Name == product.Name;

    return products.FirstOrDefault(predicate) != null;

}

And finally…

public bool Contains(IProduct product)

{

    return products.FirstOrDefault(x => x.Name == product.Name) != null;

}

We can also filter lists in a similar fashion using Where

public IEnumerable<IProduct> FindByName(IProduct product)

{

    return products.Where(x => x.Name == product.Name);

}

Update: Thanks to Conrad for helping me improve this and remove the need for an Extension Method.

Gzip Issue

A co-worker was facing down a problem with one of his asp.net portals last week and asked for some help. The full details about what this portal does are not important, but suffice to say that it would zip up some files on the server and allow users to download them.

The problem was that on one of the two servers where this portal was hosted, files were coming down smaller than the other and failing to unzip. It almost appeared that the last 5-8KB of the files was just being truncated. I spent a fair amount of time with this person checking the versions were consistent, that the configuration files were consistent and that basically nothing was wrong on the developers end.

At this point we were ready to point the finger at IIS, but we needed to be sure.

I logged onto the failing server (this is in dev), ran inetmgr and compared the IIS settings to the working server. Aside from a few false leads, everything is more or less that same. The particular site is running as a virtual directory, all the usual settings look like carbon copies of one another (security, permissions, thread pool, .net version, etc…) and nothing appears to be out of place.

At this point we are starting to think it must be in some part of IIS we were not familiar with and decide to give fiddler a try on the user’s end instead. For those that are unfamiliar with fiddler, it is a lot like wireshark except it plugs directly into internet explorer and captures all the network traffic in a much more friendly and active way. I ran into this tool a couple of years ago and it has remained in my toolbox since.

Request header for the working server.

Request header for the failing server.

Other than different session ids, they are identical.

This was the response header from the working server.

This was the response header from the failing server.

Notice the difference? If somehow you missed it, the transport mechanism from the server to the client is using gzip on the failing server. I decided to disable it for that server to see if it would fix the issue as a proof that the issue was with gzip compressing the zip files.

A quick way to disable something for gzip compression is to check if the file extension you don’t want compressed is included in the MetaBase (IIS configuration file).

The tag you want to look for is IISCompressionScheme

There is a decent step by step guide on enabling gzip compression here. The biggest tip is that you need to shut down IIS before editing the MetaBase file. There is an option to do this in the restart procedure.

That all said and done, it was indeed gzip that was causing the issue. It really shouldn’t matter if the content is compressed between the server and the browser, but for some reason none of the major browsers would uncompress the file. Another issue for another day I suppose.