Maven R|D

Five Button Guys

admin — Mon, 28 Nov 2011 06:15:17 +0000

During the past year I’ve come to a conclusion about many IT professionals that make up their departments. I’ve begun calling this archetype: five button guys.

A quick definition

Your local five button guy walks into work and presses the same five buttons in the same application everyday. As a result, a knowable and recurring problem does not happen that day. While five button fixes are quick and many times necessary, they are always a cop out. Five button fixes never get to the root of the problem.

Five button guys are defined not by the fix they are named after but by the lack of preventing the problem again. They are happy to take the easy way out EVERYDAY. Five button guys don’t take initiative to UNDERSTAND and PREVENT future five button problems.

Why this is a problem

Five button guys are a single point of failure in your organization. Five button guys own a system in that they are the only one with the knowledge of the quick fixes required to keep the system afloat. You have to wait for a specific five button guy to get un-busy to press his five buttons to solve a problem on HIS system. What happens when he goes on vacation or worse yet leaves the company?

Five button fixes don’t scale. By definition, they never fix the underlying problem. Five button guys promote a company culture having an ever increasing pool of persistent problems. Having a collection of problems that only gets bigger is itself big a problem.

Five button guys don’t promote solid system development. The lack of solid understanding of underlying technologies and willingness to take the easy way out means they will produce more five button situations. Obviously this is going to put your future projects on a shaky foundation. Businesses whose foundations are laid in understanding instead of Magic are light-years ahead of their counterparts.

An aside on Magic

Five button fixes are just one example of Magic. Magic is an assumed response to a set of poorly understood actions. Magic is restarting your computer when your network card can’t connect to your home network for no reason. Magic is accepting ‘it just does that sometimes.’ Magic is bullshit.

Magic is a problem because it doesn’t leave you with a lot of options when it fails. You end up trying to the same Magic solution, but increasing the level of applied hope. Computers respond much better to logic than hope.

Fixing the problem means fixing your culture

Eliminate five button guys by eliminating five button fixes. Identify your organization’s persistent quick fix problems. The quick fix means five button problems can fly under the radar. We can only fix problems we know about so ask around. Put some time into sharing your organization infrastructure with another group to hash out persistent reacquiring problems.

Give people time to solve the problem the right way. Allow time for root cause analysis of their five button problems. If you don’t have time, allow for analysis as they come up again. Still to many? Fix one a week. Don’t accept cop outs solutions.

Give your people time to understand the technologies they work with. Focus on shell/regex/glue languages, automation technologies, and a heavy understanding of your core technologies. Side projects and hack days are a great way to give people a different perspective on tech they work with every day.

At the end of the day we eliminate five button guys by increasing THEIR knowledge base. We tip the scale of the quick fix vs root understanding a little each day towards root understanding to make real fixes easier.

And remember there is a little five button guy in all of us. Nobody knows everything or has all of the answers. We are in all in this together.

News – 11/14/11

admin — Mon, 14 Nov 2011 05:13:30 +0000

There is a new page for blog posts. It’s structured a little differently than most blogs. Check it out here or through the menu above. Its still written and edited mostly by just me. Please be patent with any typos / errors or better yet shoot me an email through the contact page

Questions for Startups

admin — Mon, 14 Nov 2011 04:42:08 +0000

A few weeks ago I was posed with a new question.

Q: What would you ask a new start-up or set of people thinking about a starting one.

I believe that there are a lot people disillusioned about startups by the ‘quick success’ or the promise of short hours. There are no quick successes, nor are there many half days. So here are my questions, and then some comments.

Can you define you goal in less than 140 characters, without specifying underlying technologies?
What makes you different?
What makes you better?
Are you ready to make this a priority?
Are you in this for the $$ or the ‘thing’ you are doing? (The right answer is the latter)
How stubborn are you. You need to not accept failure. You need to get back up when you fall down. However, you do need to acknowledge and respond to criticism.
How attached are you to your idea? Are you willing to change with it? Your idea is going to evolve. Are you ready for that?
Are you excited ?? (‘Yes.’ is the wrong answer. We are actually looking for ‘YES!!!!! LETS DO IT!!!’ )

My Comments

This is going to be hard. You are going to need to put in some long hours, pound on doors, and not accept failure. Success takes time. A lot of time. This only works if you are excited to get up at 6:00am and sad when you have to leave at 8:00pm. You are going to have the privileged of trading in your old life. For this you get…

to leave 9-5 behind.
take your work home with you.
hold your future in your own hands.
own your failures.
make a difference
make the rules.
be yourself.

and

build something awesome !

Coding Standard

admin — Fri, 04 Nov 2011 03:56:11 +0000

A coding standard is an important part of programming. It lays the ground rules for how software is constructed and formatted . This standard has the following goals.

Reduce the “holy shit” factor when faced with a lot of new code.
Encourage a style of making software that is more maintainable and less likely to contain errors
Make collaboration easier

Naming

All variable names shall be descriptive. The only exception is non-nested for loops, where the counter or iterator variable is ‘i’

All names shall be spelled correctly.

All names shall follow the camel case convention

Class variable names shall be a noun and start with a capital letter

Method or function names shall start with a verb and start with a lower case letter.

All non-class names shall start with a lower case letter

Constants shall be written in all capital letters delimiting words with ‘_’

Private class variables start with a ‘_’

All method and function parameters start with a ‘p’

All return variables start with a ‘r’

General

There shall never be two section (10 consecutive lines long) that have the same content. Content that breaks this rule should be re-factored into a separate function or method.

All methods shall only have one return statement. Instances that break this rule should use a single return variable to keep track of return information.

Nesting function calls as function parameters shall never go more than 3 levels deep.

Comments

Class files shall be preceded with a comment block denoting author, date create, and general purpose of the class.

Methods shall be preceded with a comment block denoting purpose, parameters (including expected format), and return type.

Inline comments shall follow one of the following formats:

//–COMMENT–// comment string directly about code.

//–NOTE–// the note string. this is usually about an assumption or use case

//–TODO–// a item that still needs to be done or finished.

Documents, Files and Folders

All class shall be in separate files with the file name being consistent with the class name

All classes shall have an associated UML diagram or section in a project UML diagram (depending on the scope of the project)

All code files shall be back up on the source control server. The source control server shall never be more than 2 days out of date with any local copy.

Process

All code shall be review for correctness and understanding by at least one person who was not involved in writing it.

All instances where this coding standard is intentionally broken shall be documented in a project centric location. This should include the files and methods breaking the standard, what parts of the standard is being broken, and why that part of standard is unable to conform.

News – 11/03/11

admin — Fri, 04 Nov 2011 03:10:54 +0000

My first blog items have been posted! My goal is to provide some insight into my feelings about software, process, and software engineering culture. Please be patient with any typos, misspellings, or grammar errors. If you have any comments or want to point out a mistake I would love to hear from you. In the interest of keeping my inbox free of spam, please use the contact page

Apple Deal-breakers

admin — Tue, 01 Nov 2011 02:42:57 +0000

This post started as an email to the great people at 5by5. The email suggested that although Apple is a great company that makes great products there is still a minority they might not be be right for. Apple products don’t solve my problems, and have a list of deal-breakers that prevent me from buying in. My reasons might be menial, but they are my own.

Deal-breakers

deal-breaker: light UI. This is the biggest one. It has to do with that whole working in the dark hipster thing. In all seriousness this is a huge problem I have. A dimly lit screen and a hoodie help me focus on the task at hand. A room fully engulfed in light breaks me out of The Zone.
deal-breaker: product cost. I’m still in poor college student mode.
deal-breaker: phone data plan costs.
deal-breaker: software lock-in. One upon a time, iTunes took all my files/directory and converted them. I felt betrayed. I don’t know if iTunes still does that, but I’ve found alternatives that work great. I have no reason to return for music reasons.
deal-breaker: Safari still doesn’t render a lot of the the web. I hate flash sites like everybody else, but it’s a big deal when its between me and the content I want.

Deal-makers (My Setup)

I have a LaunchBar equivalent (Gnome Do) I press [super+space] and start typing to get to programs and folders.
Most of my writing and code is text based. Gedit , Eclipse , and Dia are my main tools.
Dark UI – with monospace green font. I have more colors for code.

Gmail is everywhere
I have one computer; I just have to manage the risk of spontaneous laptop combustion. I can always get all my critical stuff right away. I could get by with just text editors for a few days. Since laptop combustion doesn’t happen all that often I can accept a couple hour refresh. One laptop means sync is not a problem.
Backup. Since all my files are text based subversion is a great backup option.
HTML is ubiquitous. This is key for things I makes as well as web services that I consume.
shell and cron are so powerful.
Battery life. I get a solid 4 hours on my Thinkpad. That is good enough for a long US plain ride, My laptop is plugged in most of the time anyway.
Real books. You can read during takeoff and landings, I don’t have to worry about deleting digital copies or how long they will have to be in the cloud. My book will never run out of batteries.. Real books feel and smell better. Bookshelves are sexy :)
Banshee. Point it towards your music directory(s) and it sucks the music in. You have to opt in to tell it to change stuff and even then its only file names and attributes.

Skype. History, quotes, groups, video, screen sharing are totally deal-makers

Phone

I have a dumb phone. I’m at a computer for more than 10 hours a day so connecting to social networks is not a problem. An added bonus is less interruptions when I’m unplugged. There exists of a definite line of working / not working. Not at a computer.? I’m not working. My phone has a 7 day battery life.

Apple

Apple stuff is still really great. Really great. Below are some reasons why they are right for a lot of people.

It’s easier to use.
Their stuff is pretty. Really really pretty.
A lot of stuff just works. I have the time and patience to work though a ton of stuff other people would not. High impact problems don’t come up all that often on my computer and devices, but they hardly come up at all with Apple products.
Apple stuff is trendy. This is the one that most people won’t like or agree with. Many people buy smart phones to be cool. A majority of the population doesn’t need one. This is a feature or a bug depending on who you talk to.
Apple has your best interest in mind. For instance, windows shutdown time can still be around the 10 min mark. The enterprise people like waiting so Microsoft keeps it in.

Android

I like Android, but it has deal-breakers too. The data cost is still THE problem. Other than that, the number one platform problem is the scroll jitters. Android would still be my platform of choice. I’m fixing my problems not yours and I like Java better..

Just keep in mind people have different problems so solutions, however great they are, won’t be right for everyone. I sure there are some people out there that feel bad for the guy who hasn’t found the zen of Apple products. Don’t feel bad for me. I like where I’m at. My set up works for me.

Nerd Problems

admin — Tue, 01 Nov 2011 00:18:13 +0000

So nerds have problems, but nerd problems are different from everybody elses. Nerd problems are low impact / high frequency while normal people problems are high impact / low frequency. In layman’s terms, when it comes to computers, normal people have relatively hard problems that take a long time to solve, but these problems are fairly infrequent. Nerds on the other hand have problems that are easier to solve, but happen at much shorter intervals. To be clear I’m talking about computer nerds throughout this piece, but I think the impact / frequency distinction is fairly accurate for all nerds. Time for an couple of examples.

The common problem that is used in these two examples is the configuration of network adapters. As you will see it effects these two groups differently.

Normal People Problem – Your mom can’t connect to the network. When fixed, her computer will remember the password until it dies and she has the same problem come again next year, in which time she will go through the same process of asking you to set it back up for her. High impact because it takes a non-technical person forever to figure out; low frequency because it only happens once a year.

Nerd Problem – A nerd sets up so many virtual machines it is a pain to configure all of the network adapters every-time. When fixed we have an automated solution of configuring network adapters that works with our automated solution for setting up VMs. Low impact because it only takes us a few minutes to set one network adapter up but high frequency because we might do this 10 time a day.

This stem from nerd’s religious observance to process as well as insatiable appetite for finding and assimilating information. This may seem tedious but here’s the good news. A lot of nerds have to same problems. We build solutions that help out our fellow nerds everywhere. After we are done with our problems we can then solve your problems faster or get back to making the next angry birds.

Home

admin — Mon, 31 Oct 2011 07:19:54 +0000

New Again! This site is a place to show off some of my current projects and thoughts about making software. More coming soon.