N.A.D.D. and A Spindle of Prototypes

Many times in development we get crazy ideas. Not the ones like dancing naked on the bar in the latest club, but the one we think will allow us to rule the world. In those brief moments we envision pyramids, giant aligned rocks, and extremely good apple pie…with ice cream all served to us on a silver platter. When reality creeps back into consciousness we begin to think about the construction of that idea. This is where the prototype comes in.

Unfortunately, or fortunately, I have these kind of ideas every now and again. It leads to some entertaining day dreaming. When I snap to I begin thinking about how I could create that which I’ve daydramed about. It often leads to half attempted portions of an application. By the time I’ve finished hacking I have a subset of the functionality I imagined would work. This is the nature of the prototype; see a post I wrote earlier this year on prototyping.

Now, the constant Attention Deficit that I have due to my self-diagnosed N.A.D.D. means that as soon as my next big idea comes along I drop what I’m working on to persue that. This doesn’t work very well. It leads to a handful of half hearted attempts to produce anything worthwhile. Here are a few tricks that I use to make my day go more smoothly.

Break the monotony: In order to harness my ideas I tend to need to be fully engrossed in the concept. If I don’t have full confidence in what I’m doing then I lack the focus and attention required to be 110%. So, the way I combat this is by taking breaks. If I’m not fully into what I’m doing I give myself 5-15 minute breaks every 2 hours or so. This lets me recharge my focus by switching gears quickly over a short interval. Sometimes I’ll get up and walk around the office and chat quickly with someone about a random topic. But, it gets my mind moving in another direction such that when I return to my desk, I’m refocused.

Solve a problem: I try to solve problems. What I mean by this is not that I’m a problem evangelist, but instead that I work on the problems at hand rather than just trying to architect like crazy. I rather like not being an astronaut and prefer to stay that way. Plus, I tend to be far more interested in challenges, and problems present challenges.

Calling all units: When you code in pairs you have the interest levels of others to feed from. If you and another person or two other people are working together to solve a problem then you’re one step head of the game. I like to bounce ideas off others even if only for the brick-wall effect, it helps me to think through issues. When I grab another person to code with we usually end up being very productive pushing each other forward.

These couple of things help me to be as productive as possible. I try to use these techniques often as tools, just like my editor, in the sense that they can help me to be as effective as possible. When I’m done, I have a number of full featured prototypes that can be equally evaluated. This makes it easier for me or anyone to assess whether the idea really is something that can takeover the world…mwahaha.

Hire the Meta Thinker

In the past few months I’ve seen suggestions such as fire the workaholics all the way to fire the underachievers. Then you’ll see suggestions about how to hire and what to hire. What I don’t understand is that everyone is looking for specific traits, “has xx years working with J2EE, has handled a project from start to finish, has lead a team of 5+ people, has a 4 year CS degree”. What is the point? None of the above is going to really help when it comes down to producing something good. I say skip the crap and focus on thoughts and thought process. Hire the meta thinker.

I find that the quality produced from meta thinkers is far superior to the contrary. The reason I say this is because the person writing the code cares about asking what and why. Simply asking “What is this method supposed to accomplish?” and “Why am I writing this method?” starts the thought process into what will inevitably be a much more powerful set of tools.

Not only will those tools, functions, libraries, etc. be more powerful, they will be reusable. The reason I say this is because a meta thinker will think about the practicality of the functions or libraries. Meta thinkers aren’t concerned with the number of lines being produced, in fact, it tends to be the reverse. A meta thinker strives to drive the number of lines required down to the optimal level. The optimal level being the most efficient level. This ties into the “what”; the reason I am writing this function is because it allows me to create an object within the database. A meta thinker asks, how can I make this universal. How can I make this work outside of my specific scenario.

The other reason a meta thinker will produce better code is because of the “why”. A meta thinker understands that not everything requires separation, but attempts to see whether it makes sense to do so. To develop great software you will want some people who ask “why am I writing this?” One thing that will come out of that question is the finding of libraries or other tools. Also, you’ll find that the task at hand may be too complex for the purpose and realize and architectural fault in the system…Why am I really required to write ASM for this web app? Is the speed increase necessary? Maybe it’s time for a new framework. A meta thinker will find flaws less obvious than this one.

Beyond this, a meta thinker is someone you want around because you can bounce ideas off of them. A meta thinker will be able to help you flesh out ideas. These people will be able to expose issues or bless your concept. You are nearly always guarenteed to have a good idea of the more difficult parts of the operation once you’ve talked with these people.

Another reason you want to hire meta thinkers is because they are interesting to talk with. Not only do you build your level of understanding, you start to think differently. You learn and adapt your thought patterns similarly such that you’ll find yourself asking why a lot more. You’ll find that, after a period of time, you are the meta thinker.

This process is enlightening. You find that you try to solve a problem before solving the problem. Instead of diving into an issue you will think about it before and then attempt to solve the problem. This produces cleaner code and better performance, both in code efficiency and in the rate at which you write your code. By meta thinking, you find that you are solving the problem of how to solve problems. You are finding out how to write reusable methods by thinking about how to write methods. Your thoughts begin to change and your notion of just getting it done changes because you know that there is a better way.
Now think about it, would you rather work with someone that comes into the office and just does what is necessary for the day and then heads home, or would you rather work with someone that meta thinks about problems and come up with a crazy solution to a problem? I prefer the latter, it is just more interesting to me but, bottom line, I would prefer to gain more value for my buck.

The Next Holy War: Distributed VCS versus Centralized VCS

I often find myself being an advocate for something specific in the technology field. And, many times this relates to the common “holy wars” that most of us are familiar with. I sit on the emacs side of one, and the open source side of another. You can immediately understand what I’m referring to when I say “emacs”. The next topic for war I believe is going to come down to version control. If you want more proof, take a look at Derek Slager’s DVCS Myths post.
Currently there are two main types of version control and source management, centralized and distributed. I’ve used centralized systems for quite some time and although they have served a purpose…I find them to be outdated. Now, hear me out before getting frantic. The software industry is changing. We are in the midst of evolving the way we work. We want to work bigger, faster, better, stronger, right? There has been a push over the last 10-15 years to revamp our development methods. What I’m referring to here is the waterfall to agile approach of things.

The waterfall approach is about building very hard speced systems over the course of “x” to completion. Once the system is complete, you test, debug, etc. This is often very clunky, doesn’t describe the entire system, and takes an extremely long time to obtain any tangible assets. By this I mean that nobody can see a working system part of the way through. Thus, expectations are usually high leading let-downs as a result. The agile approach, in many ways, was created as a way to attack the problems at the core of the waterfall approach. Also, certain agile approaches can help do more such as improved development efficiency. With this in mind, and understanding that I sit on the agile side of that fence lets talk about source code management (SCM).

Centralized version control was fantastic. It provided the foundation for storing code in one place such that developers could work on code and then push it back into that one location. Not only was this able to happen, but we could lock, merge and tag. These are all good things by the way. What good would any SCM be without them. The lacking areas are the repository and the workflow.

Since we talked a bit about workflow above as it pertains to development, lets talk about how it relates to source management. In the likeness of the Pragmatic Programmers we know a few things to be good. That we want to refactor early and often. And, we do not ever want to settle with broken windows. These few things being said, lets discuss them as they pertain to workflow. In any SCM we can accomplish each, right? We checkout code, modify it, and commit new code. Centralized or decentralized. But, I’ve found it easier to manage the above “good things” within distributed version control system (DVCS). When I am working on refactoring code, I want to have an experimental branch. This allows me to create features, change API, and muck with the general internals of a codebase without destroying the greater good. That brings me to broken windows. If all developers commit to a central repository, then all code is based on said repository. Thus, if you have a team of n (including yourself), you can stop n-1 people from working for h number of hours in a day by commiting some code that you thought worked.

With a DVCS, you are commiting your code to a branch. This means that you are not commiting to the central repository. Sure you have to deliver your changes at some point, but you are more likely to have your code in working order. Also, it allows for easier testing of your code, since your code will be a subset of all new features and changes. So, when we refactor our code or write new features we are setting ourselves up better by having the DVCS.

Now that I’ve touched a bit on the workflow we can talk about the repository. Distributed version control systems are just that, distributed. The point is to make it easy for developers to make changes while being anywhere. The way this works is with distributed repositories. Distributed systems work by branching. Although the notion of branching is built into SVN and other centralized systems, they don’t work the same.

Distributed systems, as seen in the image, mean that everyone is a node, or using our terminology, a repository. Rather than just feeding off one main location, I can pull from my friends repository, push code changes up there or to a different repository. Branching allows for this sort of behavior.

So, when I modify code on my system and then commit it to my local repository, I can push those changes along to whomever or they can pull them down from me, and everyone has my latest changes.

So, I believe the thought going through your mind at this point is, wait…You’re contradicting yourself. If I want to commit often and refactor even more often then I’ll likely break something. Thats not good. The point here is that you shouldn’t work directly in your local repository. You should branch the repository and do work within the branch. For instance, say you are working on an OS. You can have a branch for networking. I can then grab that branch but if I have to implement some experimental IPV6 functionality, I’m not going to do so such that everyone gets those changes. I’ll branch the code base and do it there rather than expose that code to everyone. With a centralized system, you can branch the code…but merging the modifications back would be complicated and cumbersome, and in some cases not possible. If you need more proof take a look at Griddle Noise: What a DVCS gives me.
This being said, the industry uses centralized version control for most work currently. I feel that the change to agile programming should be accompanied by a SCM system that easily supports agile processes. A DVCS goes hand in hand with a distributed source management system.

There, I’ve stated my thoughts on the point. Flame away.

Low-Tech Time Tracking For the High-Tech World

To start, index cards are saving my vision. Bold statement, I know… But hear me out.

We’ve all heard it at one point or another, “Can you remember to put your time into XYZ? Thanks”. I hate that line. Personally, when I hear it I want to immediately turn around and scrape my eyes with a fork. It usually has nothing to do with the person asking the question, but instead the request itself. Time tracking has a very bad association in most people’s minds, and in general we have good reason to hate it.
For those of you lucky enough to not have to deal with time tracking, let me enlighten you. To go back to the good ol’ days of industry, employees would enter the factory, pick up their time card, and stamp it with the current time. As they were leaving “the office” they would punch it again with that time. This is particularly useful in jobs where the employees are paid hourly. You know exactly how long someone worked, assuming they worked for the entire period of time the were at the shop. The problem of time tracking is brought out of hourly salaries and into billable clients. What about situations where you charge clients hourly, half-hourly, etc… How is time tracking correctly managed here? There are a handful of solutions and most of them are horrid POS (pieces of software ;D). The UI makes little to zero sense, it’s clunky, and breaks half of the time you are using it. To get back on track, the software itself is designed to track the time you work on a project. Meaning, you enter in 1 or .5 and so on based on the time you spend on a task within a project. You do this for each project you work on, and everything in hunky dorry (don’t ask me to explain that). The time is then aggregated for everyone working on the project and an invoice is sent out to the client. Seems simple enough right?
Here is the fundamental problem. With what I said above in combination with, people are just farkin busy, most of us don’t have time on a project to project basis during the day to enter the time we spent into the system. So the accepted idea is that you should wait till the end of the day, and then log your time. In theory, thats great. It doesn’t work out. By the end of the day, all I want is to go home and have a beer. That and I’ve forgotten about time tracking, even though it is on my calendar for every day at 5:30PM. I have a lot of other things going on as do you I presume. The point is that I’m not going to enter my time during the day or even daily. But, that does not discount the validity of how important it is to accurately measure the time spent on projects. We need to be able to bill clients accurately, no?

The solution that has been working for me so far has been an incredibly low-tech solution. I’ve been using index cards. Moving back to that old paper and punch type of method, I’ve been able to more accurately record what I’ve been working on. This is good because it provides me more time to do other things. Before I had to trudge through my email and calendar appointments and then try to remember back about what I did on that day last week between X and Z… The idea of using index cards was presented by the president of the company I work for. We were discussing time tracking and how much our current system sucks and he mentioned that he had read about another company using this approach. I asked our office manager to grab me a set of those index cards that are bound together and tear away. He did so and it seems I’m usually far more billable than I used to be.

The process I use to track my time is this:

1. Start the day off by tearing off an index card.
2. Flip the card over and write the date on it.
3. Take the card with me wherever I go (meetings or otherwise). This works because it’s so small it can fit in my pocket or I can carry it as if it were a page in my notepad.
4. Whenever I remember or think of it, I write down the task and the time associated with that task.

This process, on a daily basis allows me to more accurately gauge how long it is taking me to do tasks within projects and to more accurately bill my time. When Monday morning comes, I can spend 15 minutes dumping the time I’ve already collected into the time tracking application rather than an hour fighting with email and calendars. Also, it reduces the number of times I have to actually enter that god forsaken time tracking application.

Therefore my initial line stands; index cards (and sanity) are preventing me from stabbing myself in the eye with a fork. Happy tracking.