StackOverflow - Garbage In, Garbage Out

I have been using stackoverflow for over a year now. It surprises me how great the answers you can find there are and in some cases, the pure quality and effort some individuals will put into them. Take this iPhone question for example.

A stackoverflow user is asking a question about the best way to pass data to ViewControllers in the iPhone (Which uses MVC for its UI). The top answer there is both informative and useful in that it provides a concise answer, as well as, example code to get the user started. Obviously this question took time out of someone else's day to think about and reply, then edit and update. Truly a wonderful example of the simple yet highly valuable resource stackoverflow can be.

Then you get questions like this one. I've seen that question both asked and answered over and over for years now. I've even asked it myself at one point and let me just say that providing an explicit answer to that question never did me any favors. The question is born out of looking for the wrong solution. The stackoverflow user, in this case, is looking for the wrong solution and getting it handed to him on a silver platter.

This is just like using a calculator, they always give you an answer, they don't always give you the right one. Stackoverflow is full of people eager to give you an answer to your question, but no one will spend the time questioning the origins of it.

sp_help

I am ashamed to admit I never knew about the sp_help and sp_helptext commands in sql server until today. Why has no one ever shown me this earlier?

sp_help will find a stored proc by just providing its name. It will then show all the matches, where they are located and what parameters they take.

sp_helptext will something similar, expect it will display the actual stored procedure. Much easier than hunting through a list.

Programmer Professionalism

I repeatedly hear, as a programmer, that I should be concerned with my overall professionalism. I should be concerned with the quality of what I produce, the knowledge and experience that I have obtained through work and education and the attitude I bring towards solving complexity.

I should be a professional, no different than say a doctor, a lawyer or an engineer. Engineer is even in my title, it is so clear.

On the other hand,  I also feel that I should be more like a tradesman or a craftsman. Learning under a master on a linear path that never ends, always improving.

Here is an analogy that I used to describe programmer to my father, a tradesman.

Working as a programmer is not too dissimilar to building a house. There is an initial design, planning of the work, sign-off on everything  and then the actual building commences.

Only recently have we started practicing the fact that the user must be involved if we want to succeed. The strict set of rules to follow in design are always changing, especially if the designer is constantly self improving, as they should be.

Programmers must both design and build the systems they work on. They are a tradesman (builder) and a professional (designer). With all these different expectations and the only constant being change, it would be surprising if one person was capable in one of these directions.

We will probably never have a clear Apprentice to Journeyman to Master tradesman approach nor a professional accreditation. What we will have is the highest expectations any career has known and so much change that we will never be able to agree on things of consequence.

Object-Oriented Design Basics

In order to achieve each of the metrics defined previously we can employ some very fundamental techniques. Techniques that should appear to be common sense, hopefully. Though broad in scope and concept, they are the basis for much of what we currently try to achieve in programming.

Abstraction

The notion of abstraction is to distill a complicated system down to its most fundamental parts and describe these parts in a simple, precise language. Typically, describing the parts of a system involves naming them and describing their functionality. For instance, take a design pattern such as the Abstract Factory. When I use this pattern, declaring its name in the class definition, I am telling the next programmer what this class is supposed to do without documentation and without comments. When I declare some class called, CarFactory, a programmer should know that an instance of this class with provide instances of Car objects.

Encapsulation

Another important principle of object-oriented design is the concept of encapsulation or information hiding. Encapsulation means that different components of a software system should not reveal the internal details of their respective implementations.  In general terms, the principle of encapsulation states that all the different components of a large software system should operate on a strictly need-to-know basis. There is a common saying surrounding this, “TELL, DON’T ASK”.

One of the main advantages of encapsulation is that it gives the programmer freedom in implementing the details of a system. The only constraint on the programmer is to maintain the abstract interface that is visible. Encapsulation aids in adaptability because it allows the how to change without altering the expected outcome.

Modularity

In addition to abstraction and encapsulation, a principle fundamental to object-oriented design is modularity. Software systems typically consist of several different components that must interact correctly in order for the entire system to work properly. Keeping these interactions straight requires that these different components be well organized. In the object-oriented approach, this structure centers around the concept of modularity, which refers to an organizing structure in which different components of a software system are divided into separate functional units.

The structure imposed by modularity helps to enable software reusability. If software modules are written in an abstract way to solve general problems, then modules can be reused when instance of these same general problems may arise under a different context.

Problematic Processes

I have always disliked following process for the most part. There is something dehumanizing when I enter into the conversation where I am told about some event and then told what I am expected to do. I understand what processes are in place for in the broader sense and often try to discover the particular reason for each process before I will follow it. Generally though, the employer wants workers A through Z to all behave in a similar fashion. Why though?

Consistency. If all your workers do the same thing, then they will be consistent in their day to day work. This also means they are predicable and replaceable. Each worker is desired to be a replacement for any other as long as they follow the same processes. Is that a good thing?

In some case, I would argue yes it is. There was a time in my life when I worked on an assembly line  and process would make or break the productivity. Each day followed a specific process, breaks followed a process, each task always had a specific and predicable process. When the feeder has space, put in another tray. When the pallet of trays are gone, get another pallet. Very rudimentary process that is basic and practical. Often this process is the discovered best techniques of what you are supposed to be doing and essentially giving you the optimized way to do each task. Do this because it has proven to be the fastest or most maintainable way of doing things. Great I say.

However, bureaucratic process is a whole different beast. The domain is larger, the number of employees usually greater and the types of tasks being done much more complex. Process in this case is often more to do with getting each groups interests met rather than providing the most efficient or maintainable way of doing things. That is the part I dislike. A giant muddled mess of wide concerns, each at a different level of importance based entirely upon your current job, department and/or pay grade. Yuck.

Thinking about how many concerns are no longer valid or important will only depress you further. How much of your day is spent doing tasks that don’t provide any benefit to you, your employer or your employer’s customers. You can tell things are bad when you ask, “Why do we do X?” and you get a response such as, “Because legal wants us to” or worse, “Because I told you to”.

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