Data is a Brick

I have often used the analogy of a brick to describe the ideal user interface. A brick is immediately understood by everyone, easy to use, and can serve multiple purposes: a tool, a weapon, a paper weight, to hold up the end of a desk, build a wall, etc. But the brick idea extends to data as well.

After a discussion with some of my colleagues about “data hydration”, it occurred to me that the metaphor (and therefore the premise) is wrong. Hydration, sponges, and vessels are not part of the real metaphor (in fact, try to find examples or definitions of data hydration online). There are no idioms in the programming vernacular that match the hydration metaphor. Data is NOT a sponge. Data is a brick - it has structure and is immutable. While it can serve many purposes, it is still just a brick.

We already have the “assembly” in our vocabulary, so let’s extend that to the example of an assembly line. The function of an assembly line is to take a series of parts and “assemble” them. Our colloquial assembly does essentially the same thing. It is a set of blueprints (class definitions) for assembling bricks (data) into a cohesive and meaningful structure. No H2O involved.

Lessons from the Road Redux

In the first installment, I laid out what was working for me during an on-site project. The project is complete and been in production for a few weeks. I wanted to share the results based on my previous assertions:

• TDD Works
• Access to the Client Works
• Spec-less Design Works

The project was completed successfully and under budget. We were even able to add items to the project that were outside of the original scope. The client is happy, their clients are happy, and not a single bug has been reported.

Please understand, I have not published these results to be braggadocios, but rather to illustrate that these things do in fact work. If we are diligent and disciplined, if we follow these processes and techniques, we are not guaranteed success, but we are garnering a posture that is fundamental to success.

This is Why We Write Unit Tests

[StringLengthValidator(0, 29,
MessageTemplate = "Material cannot exceed nineteen (19) characters.",
Tag = "Material")]
public string Material { get; set; }

This is a snippet of code that makes use of the Validation Application Block’s attribute validation. Can you see where the problem is? Which rule is correct? 19 or 29?

Unit tests for both string length boundary conditions and the return message would have caught this bug. Is it a small bug? Yes. Does it matter that it’s a small bug? No.

This code will be rejected by QA and now it must be fixed, re-deployed, and regression tested. If QA does let it pass, then you have to contend with the client rejecting it. This is a much bigger loss because on top of the QA process, you have UAT and re-deployment to production and all of the people and processes involved with that. Unit testing (and specifically TDD) helps us prevent bugs from finding their way into our codebase.

Think of the time, effort, energy, manpower, and money that would have been saved by spending an extra few minutes to write three or four units tests.

Is Software Really Like Building a House?

I’ve heard this analogy used to describe the software development process and decided to try and find the similarities between the two. In attempting to find those similarities, it is clear that they are not similar (in the spirit of full disclosure, I just finished building a house).

First, software does not require any special permits before a project can begin. We may require a work order, but that is not a permit issued by a governing body or regulatory commission. Software does not require specialized sub-contractors (electrical, foundation and concrete, flooring and carpeting, lighting, plumbing, paining, roofing, finish carpenters, surveying, grading, landscaping, welding, HVAC, etc.). As developers, we may take on different roles during a project, but we all must have some knowledge of each aspect of our craft (database, UI, testing, debugging, etc.). Also, the cost and time of building a house depends on the availability of the materials. All we really need are a text editor and a compiler to get a project started.

Building a house is a tried and true regimented process with a schedule of interdependent events. If you pour the slab before the underground work has been completed, then you are going to have to remove the entire foundation, rebar and all, and start over. You cannot install the roof, before the walls have been framed.

In software, you can choose to start at any point, in any layer, with any class. There is no predefined hard scientific method to follow when writing code. Multiple people can work independently on dependent items and fuse them together later.

Each step in home construction has a procedure. Framing, plumbing, painting, and all of the other crafts involved, have a specific set of standards and procedures that they must follow no matter the size or shape of the house. In fact, if those standards are not rigidly maintained, a building inspector can shutdown the entire project. A code review does not really measure up to that standard.

Software is a profession of problem solving. Sometimes those problems are so complex they takes years to overcome, but we do not build houses. We provide solutions.

Working Smart

There is an old saying that goes “the laziest people are the ones that work the hardest”. At first glance, this may seem like a contradiction, but what are the repercussions of lazy or “get ‘er done” behavior?

First, a lazy person does things in a disorganized, haphazard way, just to get the task done, so they can return to lounging on the couch and eating cheese puffs. Second, they don’t ask for help, so it takes much longer to accomplish the task. Third, because they are usually shooting from the hip, they make a lot of mistakes that require more work and the cycle begins anew.

Let’s look at this from the perspective of moving a piece of furniture. That bookcase really needs to be moved, and I know it is too heavy for me to move by myself, but I’m going to do it anyway. I not going take the time to see if the doorway is big enough to get the bookcase through, so I will just to force it. Now the bookcase is scratched, and the molding around the door has been damaged. Since I didn’t take the time to figure how I was going to move this huge, unwieldy piece of furniture, I have left scratch marks all the way across the hardwood floor. What could have been an easy task had I taken the time to think it through and maybe even ask for help, has now turned into a whole weekend of repairs to the floor, the bookcase, and the door frame.

Take the time to do it right the first time and save yourself the pain of being lazy.