mobcode

No frameworks

Never say you plan to build a framework. To a project sponsor this is just a code word for:

I want to take your money and burn it. I want to dissapear for a long time and build features that don’t match what you need. I will make a big pile of code and tell you endlessly how it is so cool, because if you want you can plug in any kind of object you want. I will work on this endlessly and get upset when other people violate the rules I create. Until I leave the project, and then it will be a thorn in your side until someone else writes another framework and builds an adapter layer on top of my framework.

Even if you plan to build a framework, never say the words “I will build a framework”.

Instead think of it like this: you will deliver the needed features and in the process apply good design to remove duplication. This emphasis on the needed features will keep you grounded in the real needs and keep you from getting off course in a framework fiasco.

Semi-professional names

When you are doing work on a project you want to maintain at least a semi-professional image.  A highly visible part of your image is your email and IM address.  Use an address that is a variant of your name.  This also makes it easier for team members to keep track of who you are.

Avoid goofy name like “l33td00d” or “drdeath”.  These names will just alienate the people you want to hire you.

Communication is broken

Human communication is deeply broken. We have half-baked ideas. We don’t realize how our subconscious twists our perception of reality. We don’t understand ourselves. We have difficulty expressing our ideas. We each have different definitions of words. Our emotions get involved and confuse things. And then when we say something we don’t speak clearly, or we speak too quietly, or we mumble, or we talk over each other. Not to mention language barriers. Not to mention how online communication masks our tone so the other person can just make up any tone they want to go with our words.

Then the other person tries to piece together our body language, tone of voice, and possibly misunderstood words to follow a similar process in reverse to figure out what we are saying.

It is a wonder we get anywhere at all.

So, what to do? It seems to me the best we can do is:

• Think carefully and well.  Then try to express ourselves succinctly and clearly.
• Be patient with others. They are struggling with the same issues as they try to understand you and as they tries to talk to you.
• Stop talking and listen to others for a change.

Don’t go dark

I first read the guideline “Don’t go dark” several years ago in Jim McCarthy’s The Dynamics of Software Development (a most excellent book). I think I understand it better now than ever. Developers like to take a programming task, dissapear into a hole for a long time, and then re-appear with a beautiful solution. I think developers do this because it is much more enjoyable to get lost in the code, their own creation, rather than have discussions with users and sponsors about what the software needs to do and when it needs to be done.

But developers do this at their own peril. It is not very satisfying to be on the other side of this behavior. It is hard to predict when or if developers will reappear. The lack of communication also clearly shows in the product. It either doesn’t get done on time, or it doesn’t do what it is supposed to, or it does it in an unacceptable way.

Yes, it is painful to talk to pesky users and sponsors about requirements. Yes, it is painful to submit your code and design decisions for review. But enduring this pain is part of the discipline needed if you are playing to win. Endure the short-term pain and be assured that you are more valuable for doing so.

Tangled dependencies

Graph out the package dependencies in your code (with a pen and paper if it simple or with Graphviz if it complex). Is it a tangled mess? Are there lines going every where? Numerous dependency cycles? That means your code needs design applied to it. No one would set out to build such a mess. Read Uncle Bob.

A developer’s job is to create abstractions. It is hard to create abstractions when everything depends on everything else.  Those aren’t abstractions, they’re globs of mud.

Source file sizes

Here is a quick way to gauge the quality of your code. Look at the size of the source files. Typically there will be one really big file, a few medium size files, and then many small files. This is the natural state of code. All of the functionality accumulates in one place. That one place is often a single class. Most of the code lives there and uses the instance variables as glorified global variables.

This distribution of the code shows the code is not designed. You didn’t spend the time to identify different parts and tease them out as separate modules. Instead you just let them all accumulate in the easiest place possible.

If you sat down to design the code, you wouldn’t decide to lump it all together in one big messy place.

Therefore the presence of a single source file much larger than all of the others is a sure sign that the system was not designed, but just happened.

Keep on going

You are going to say some stupid things. You are going to have some ideas that turn out to be really bad. You are going to write some code that is awful. Don’t dwell on it. Keep going forward.

Consider such major flops as Microsoft’s Hailstorm, or Joel’s Hungarian notation madness, or Pavlina’s bizarre million dollar experiment. The key point is that if you try to criticize these people based on their past blunders your voice is drowned out by the flood of work they have done since then.

This is related to Joel’s Fire and Motion theory.

The key is to keep producing, and to produce so much goodness that it drowns out the stupid things you do. Build up a solid history of delivering quailty work. Then when you do something stupid, just move on, and do something good. Do so much good work that anyone focusing on your mistakes will be irrelevant.

There is no tomorrow

You know what needs to be done. But, the continuous press of crises prevents you from doing it. If you continually allow yourself to be carried along by urgent items and neglect the important ones, then you will fail. If you cannot make time to do the important things today, if you tell yourself that you will do them tomorrow, then you will fail because there is no tomorrow. Tomorrow will never come.

So make time each week and make time each day to do the important things.

This applies to you personally. This applies to your development work. Don’t say that you will clean up the code tomorrow, don’t say you will write some tests for your code tomorrow, do those things today.

This also applies to your development planning. As you schedule work to be done, make explicit plans for “strategic” items. These typically will not be part of delivering an immediate feature in a product, but they will enable future features. For example, hiring more developers, implementing an automated build server, or adopting a new development tool.

NOTE: Don’t allow these important items to keep you from delivering new features each week.

Connection-oriented IM

There are a couple of different modes of IM discussions. One mode is just sending a few random comments back and forth sporadically. In comparison to a TCP/IP protocol, this is UDP communication. Connectionless. Simply “best effort” transmissions to someone on the other side. Either of the parties may be coming or going. There may be long lags between comments. Either party could dissapear at any time.

The other mode is connection-oriented like TCP. You confirm the other person is available. You talk. You send ACKs. As you send messages you confirm you receive them. You implement keep-alives and flow control by saying “hmmm…”, “let me think about that”, “let me try something”, “I’ll be right back”. And then when you are leaving you tell the other party because it would be rude to just dissapear on someone who is expecting a response.

Both modes of conversation are widely used and appropriate. But, when communication with team members on a project it is polite to treat conversations as “connection-oriented”. This shows greater respect for the other person and offers greater opportunity for meaningful conversations.

Particular frustration arises if one party is folowing the protocol for a connection-oriented discussion and the other is connectionless. It is also frustrating to switch modes in the middle of a conversation.

Your guideline when working on a project is to prefer connection-oriented communication. If you cannot support this protocol all of the time then you should at least implement it part of the time and let the other party know when you cannot.

Road crew

I see a crew working on the road. About eight guys. They are all standing around. Leaning on their shovels. Talking. Except for one, one guy is in the midst of it all working his heart out. I always have the feeling that it is the same guy working all of the time.

Software teams can end up the same way. There is a team of 10-20 developers ostensibly “on” the project, but when something really needs to be done it is always the same couple of people that jump in and get it done.

So think about this and make sure that you are the one down in the ditch doing the work. Just as anyone driving by can see who is working on the road crew; the project sponsors will know who is getting the work done.  At some point the sponsors will ask, “why are we paying these people to stand around”.