Hiltmon

On walkabout in life and technology

The Argument for Coding Standards

cbloom rants in The Mature Programmer on the value of coding standards:

Strict coding standards are actually an intellectual relief because they remove all those decisions and give you a specific way to do the syntax. (The same of course goes for reading other people's code - your eyes can immediately start looking at the functionality, not try to figure out the current syntax)

Don’t forget that using a great architecture, having great conventions and a strict coding standard takes this up to the next level.


Aside: I also love his definition of a mature programmer (spelling corrected):

The mature programmer manages their own time and productivity well. The MP knows that maintenance is as much work as the initial writing and code always takes longer than you think. The MP knows that any changes to code can introduce bugs, no matter how seemingly trivial. The MP knows that premature optimization is foolish and dangerous. The MP knows that sexy coding like writing big complex systems from scratch is rarely the best way to go. The MP does not get into ego competitions about who has the prettiest code. The MP achieves the best final result in the minimum amount of time.

Hiltmonism - Automate or Die

Computers are excellent at performing dull repetitive structured tasks, yet many organizations use armies of people to perform these tasks. Computers are also great at following along the same mind numbing process over and over again (we call this programming), yet we tend as users of computers, to perform these tasks manually on our computers.

Today’s Hiltmonism is very simple. Automate or die. Make the computer do the work so you can have a life.

Why automate your business flows? People make mistakes, call in sick, forget to perform tasks, leave and get things wrong. A computer, when properly programmed, gets it right all the time. Automation was supposed to free us humans from drudge at work, and I believe that software is the solution to this. Reconciliation’s, automate, sending data out, automate, integration, automate, repetitive process, automate.

Why automate on your computer? If you find yourself inputting the same commands over and over again in your computer to deploy a product, you should automate. Testing, automate. You already use it. Makefiles, project files and IDE’s automate the complexity of compiling software for you.

Automation can and does fail. Programs crash, the environment changes, exceptions happen. It is here where people are needed. When automation cannot complete a task, alert and document the exception and allow people to deal with it. People are great at solving problems and dealing with exceptions, as long as they are not overloaded or mind numbed by drudgery.

How do I know this works? With comprehensive automation, my software ran a 900 million dollar hedge fund with two back office guys and an accountant event though we had many funds, brokers, administrators and systems to integrate. The people dealt with exceptions, and we never saw the actual processing going on.

So next time you find yourself repeating a task over and over again, at work or on your computer, automate it, and get a life.

This article is part of a series on Hiltmonisms, a series of catch-phrase ideas that I have been learning, developing and using for years to improve my craft and the craft of those around me.

The Best Steve Jobs Quote

This may be it.

"When you grow up you tend to get told the world is the way it is and you're life is just to live your life inside the world. Try not to bash into the walls too much. Try to have a nice family, have fun, save a little money. That's a very limited life. Life can be much broader once you discover one simple fact: Everything around you that you call life was made up by people that were no smarter than you and you can change it, you can influence it, you can build your own things that other people can use. Once you learn that, you'll never be the same again."

The Four Hour Rule

Programming is a craft of the mind. Programmers need to think through the feature they are writing, build up the code and a solution in their heads, maintain the product architecture, structure and conventions in the background and plan and design the next part of the code they are assembling. And then they need the time to execute all that. Once in The Zone™, programmers are exceptionally productive. But The Zone™ has limits. A four hour limit.

Interrupt them, and it all falls apart. They lose their primary thread of thought, the code fades away, the next step wanders off and their brilliant plan evaporates. The Zone™ is gone. To replace it, they have to return to the real world, to reload language and social skills, attempt to recognize where they are and who they are, and why they are back in the real world, and who the interrupter is.

You’ve all seen it happen. Walk up to a programmer and interrupt them. For a second or two they do not respond. You think they did not hear you. Then they blink, shudder, slowly turn towards you and stare blankly at you for a few moments more. Then, and only then, do you see recognition in their eyes, and annoyance in their scowl.

When you interrupted them, they tried to hold on to The Zone™, and failed, again. While they stare at you blankly, they are reloading. And they are annoyed because they may have just lost The Greatest Algorithm of all Time™ in The Greatest Zone of all Time™.

It takes between 15 and 30 minutes for them to get back into The Zone™, assuming they can. If there is some projected activity within the next four hours, and there usually is, there is no point trying to get back. Better to do something else.

To get back into The Zone™ they have to reload the feature into their minds, reload the architecture and conventions, and start again in planning and designing the feature because its usually impossible to get back what they had. Since it takes so much work and so long to get back in, it’s not worth going through that unless they have a four hour window ahead.

Once back in The Zone™, they get back to being awesome.

The Zone™ time itself is unfortunately bounded by biology, fatigue, or semi-social activities such as lunch, meetings, emails, going home, exercise or personal hygiene. Lucky programmers get two Zones™ a day. Once in a blue moon, you get three.

So if you are wondering why a programmer is not working hard half-an-hour before a meeting, or just before lunch, or at the end of they day, know that they have determined that there is no four hour window available to them for the near future, and are doing something else.

And if you are wondering why they always seem annoyed at you, its because you, yes you dear reader, are The Zone Destroyer™ for interrupting them.

TL;DR No Zone™ available, no ability to code well.

Disclaimer: I don’t really own a trademark on The Zone, I just think it looks cool in the article.

E-reader Roundup

Marco Arment, developer of Instapaper, writing in an amazingly comprehensive review of current e-readers (including e-ink devices and new low-end tablets), writes

If you’re primarily in the market for an e-reader, get an e-ink device. And if you’re looking for a tablet for apps, games, and videos in addition to reading, unless the iPad’s price is absolutely out of the question forever, I suggest getting the iPad.

And the e-ink winner unsurprisingly is the current Kindle (called the Kindle 4 in the review).

The low-end, non-touch Kindle 4 is actually my favorite e-reader today. It lacks the easier text selection and periodical navigation of the touch readers, and it’s effectively impossible to type on, but neither of those interfere with the most common actions when reading. It’s faster, thinner, and lighter than all of the touch readers, the interface makes the most sense and is the most responsive, and it works best with Instapaper.

No Service Competition in New York

Just a quick check on my choices for 21st century data services available at my apartment in New York city:

Internet, Landline, Television

  • Time Warner Cable
  • Verizon FIOS

Oops, only TWC from today based on the agreement reached where Verizon quit the land-based business (See Susan Crawford’s article: Smug and chagrined). So no choice.

Mobile Phone

  • AT&T
  • Verizon
  • T-Mobile (still a dead spot after 8 years)
  • Sprint (same as T-Mobile)

Neither work well, so I have to stick with AT&T because at least they have a MicroCell. Until the iPhone 4S came out on Verizon, their phones were no good for overseas anyway. Average 1 not-dropped call a day.

Sounds like I have a choice between one expensive carrier or another that both offer terrible service. So no choice.

I guess this is how the free market ‘works’?

Data Caps Don't Work

Nate Anderson, writing for Ars Technica in Data caps a “crude and unfair tool” for easing online congestion

Internet providers argue that they need to impose monthly data caps on their users in order to slay the "bandwidth hogs" running wild and free through their networks, goring ordinary users with their tusks when all those users want to do is view some funny cat pictures online after a tough day at the office. The idea is that a monthly quota can reduce the amount of network congestion during peak hours throughout the month. Fact or fiction?

One piece of new research argues that it's fiction. "Our analysis confirms that data consumption is at best a poor proxy for bandwidth usage,"...

Felten clearly finds that the heavy data users are actually not the cause of congestion, whether peak or off peak, and that data caps do nothing to help.

Explain the Problem - Not Your Solution

Something that drives me quite batty is when people turn to me for help and request a solution without explaining the problem. In other words, they tell me their answer to a puzzle, without explaining what the puzzle is, and expect me to understand what to do. They want the answer to be 42, but what is the question being asked?

This happens a lot in software design. The client calls up and tells us they want something done a specific way. They are telling us how to implement a feature, without explaining what the feature is or why it needs to be done their way. Since they don’t understand the architecture of the product, they usually don’t understand the impact of the request. And since they are approaching the problem from a non-technical perspective, their proposed solution may not technically work.

Now if they told us first what the problem is in detail, then their proposed solution, we can contribute to the discussion. We can laud them if their solution is great or present alternatives with lesser impacts because we now know and understand the problem too. And we can implement the chosen solution better because we also understand the problem better.

I am not sure I understand why people communicate this way. Maybe its embarrassing to explain a problem, or people feel they are being helpful by providing a solution. Maybe its human nature to only present solutions because, in doing so, they are proving their worth. Or maybe because they have found a single solution, and they are just plumb proud to announce it.

Whatever the reason for this communications flaw in all of us, it’s not good for great software design. Great design comes from finding multiple solutions to a problem, attacking it from different angles and mind-sets. Mosly, I find just dicussing the nature of problem exposes a myriad of possible solutions and alternatives, and that discussion leads to better software.

So next time you talk to a software person, start the conversation by describing the problem you are having in detail, and then, when they understand the problem, offer them your solution. Or better yet, walk them through your thinking to the solution with you. And listen when they offer alternatives, they do see things from another perspective. It makes for better communication, better software and much better solutions.

Hiltmonism - Close to the Business

The best software designers and developers are the ones who completely understand the business and flows for which they are creating product. This understanding allows them to apply their technical skills to business problems and create great product. And the best way to understand is to be a part of the business, to be close to it.

Drawing on my career to date, the best products I have made have all come from me being right in the thick of things. I spent 8 years writing leading edge hedge fund management and financial software, while sitting in the middle of a trading floor, surrounded by traders and analysts and accountants. Before that I worked on financial systems deployments, surrounded by accountants and managers. And before that, right at the beginning, I wrote software to sell trees, surrounded by the people who grew and cut down those trees.

Most IT people have the opposite experience. They are placed in a corner, on another floor or in another building from their clients. They work off of specifications generated by legions of managers and middle-people who may or may not know what they are doing. They are expected to create great software product and yet never come into contact with their clients, nor do they even get to see what their users actually do. Its just not possible for them to make great products.

I learned this Hiltmonism from a retail company back in Cape Town in the 1980’s who came across it quite by accident. They had automated their business, but their old head office wiring could not take the load. So they purchased a few shipping containers, plonked them down in the parking lot, installed their minicomputers and phone lines in them, wired in external power and air conditioning and squeezed their IT personnel inside. These containers quickly became hot and stuffy and very unpleasant. The CTO did not want his staff working under these sweatbox conditions, so placed them wherever he could find a spot in the old building, usually in the same space as the departments for which they were building and maintaining software.

And something wonderful happened. The analysts got to know their users, what their users actually did, and why, and how. They got to talking with them and then started applying their knowledge of technology to the problems identified by their customers. Slowly, tentatively, they started recommending newer and better processes, initially small shortcuts and later full solutions, ways to automate repetitive tasks, improve the performance of processes, leverage technology better and even do things differently. And slowly they became part of the planning and decision making process in that department as well.

Because his IT staff was close to the business, they made better software that better met the needs of the business. Lesson learned because the wiring was old!

I believe that a good software designer should take it further. They should not only get to know the customer, and what the customer does, but even perform some of the customer’s activities to get a feel for them. Learn the customer’s language, norms, jargon so better to communicate with them. Spend time in the same environment as the customer to learn the quirks, frustrations, rules and other insider information that customers take for granted. Spend the time to become part of the team.

Then, and only then, apply a computer scientist’s mind to the business and amazing things will happen. Software designs with new flows, better processes, automation, out-of-the-box ideas, even new business opportunities emerge with ease. Customers get to learn the value of your insight, become part of the design process, are there to help when you get stuck, and will provide all the information you need to make their software great.

*Be close to the business**, and you will create much better products.

This article is part of a series on Hiltmonisms, a series of catch-phrase ideas that I have been learning, developing and using for years to improve my craft and the craft of those around me.

On Designing Web Applications Balancing Identity, Usability and Familiarity

Graphic design without understanding the user, the flow and site interaction leads to pretty, uniquely identifiable web applications that are quite unusable and fail to connect with their users. Web applications that mimic the graphic design of others may seem to be more useable, because they are so familiar, but look like someone else’s product, have no identity, seem bland and boring, and also fail to connect with their users.

Somewhere there has to be a balance between familiarity, identity and usability, in a design that engages users. Here is how we found it.