Communication

As companies expand, the people within them start to specialize. At such a point, some managers will conclude that they have a “keep everyone on the same page” problem. But often what they actually have is a “stop people from meddling when there are already enough smart people working on something” problem.


And on every project, assign one person to make sure that communication happens — but only the right communication. Otherwise the team will just start having long meetings with everyone there and, frankly, people will socialize, and bloviate, and speechify, and argue about things they don’t really care about just to hear their own voices.
Joel

Code Makes Money While You Sleep

A Business post?! Yes, I still work for a living. With classes out of session for holiday, and thus a shifted focus to what is happening at work, I have some thoughts. There is a fundamental difference (in my mind at least) between a software house and a consulting house. This difference manifests itself in the house’s culture and view of the wider world. I write this with a critical voice towards the place I work (and yes I have already shared these thoughts with them).

Executing is one thing. What you choose to execute is something else entirely. When projects go long and over cost you have to ask why. Are you thinking like a software house, or a consulting house? Are you listening directly to one client and their immediate need and schedule? Or are you surveying the wider field and wider needs?

This principle of a software house comes down to a singular thought. A good line of code needs no energy or thought. The more users you can get to use a good line of code means you make money without spending any energy. Software makes money while you sleep; it is the equation of how to turn code into money.

It takes longer to write a good line of code than a shitty line of code. It is good informed code that covers a real need with many different user needs. Developers get angry if you try and ship their prototypes. The prototype might “work”, but there is not a single good informed line of code in there. In the long run you pay much more per line of bad code than for good code. With good code you pay to fix the problems before they get put into code. And it is always cheaper to fix problems on paper. The first rule of business is you get what you pay for. If the business decision calls for a shitty line of code rather than a good line of code, you’re going to pay for it. Not today. Maybe not a week after it ships. But you will pay.

The toughest part of the equation is to get all the information you need to write a line of good code. There is a world of difference between the real need and perceived need. Too often people buy into the client’s perceived need without finding the real need. Toyota became the top car company because it asked Why? five times. “Why are we doing this project?” “Because our client wants it.” “Why do they want it?” (At this point the PM will give you a snarky look.) “They need this piece of data to make a business decision.” “What is the business decision?” “I do not know.” “What will sway their decision?” “I do not know.” Why decisions are made is often never recorded. (As an aside I love Rand’s analogous Malcolm Events for making this point) So many times I have been over and over a piece of code or spec item wondering, Why? Every line of code becomes a precedent for making a good or bad decision.

If you can find answer to the final “Why?” you can spot trends and similarities between projects. And then you can focus on writing less code, good code, informed code, that solves the real Why. The real Why that is going to make you money while you are sleeping.

This “Why?” question is hard to get at. Years ago another developer (you know who you are) and I were responsible for the rewrite of the largest part of a product. I sat in a meeting with one of the project managers, and a founder who had domain expertise. He was telling me how the user interface should work. I kept asking “Why?”. He got very upset and said I could leave now. I told him I needed to understand who the user is, what they know, and what they are thinking about if I am going to do this project. He thought that communication was the means of organization. He wanted to communicate to me precisely how something ought to work for him, rather than discover how it ought to work based on the user. When it came down to it he knew all the answers to “Why?”. (Aside: I was later fired for being combative).

On the surface it is really hard to tell the difference between a good line of code and a bad line of code. It becomes easier when you’re looking at large chunks of good or bad code. But you only know it is bad because you keep constantly getting sent in to fix it. Bad code is uninformed code. It knows nothing about the real need. Good code knows what the need is. It is informed code. And writing informed code is what needs to happen if you want to function as a software house. It is always easier to fix anything before it gets put into code. Good code is going to cost less in the long run. The business folks making the decisions in a software house work to make sure that good code is written. Good code can only be written with plenty of time, and plenty of information. You cannot “rush” good code. Good code makes you money while you sleep. Bad code makes your pager go off while you sleep.

On Clients

Do not ask your clients what they want. Tell them, and sell them, what they want. If you know your clients and your market – they will buy it. To ask them what they want is to refuse to do your job as a product manager. You are asking your customers to do your job for them. And they are not going to spend forty hours a week at it. That is all I have to say about clients.

Formula One

The Formula One Metaphor

Geek Hero

There Is No Process

Stop arguing, defining, and writing down processes. It is a waste of time. There is no process. The only process is thinking on your feet. Including only who and what you need to. We’re all adults. We’re all smart. Process gets in the way of progress immediately.

Tight Feedback Loops

Feedback loops need to be tight. By tight I mean clear and short. When they get lossy and take forever – everyone does a poor job. It doesn’t matter if this is a research project that was a result of meeting, or a client-facing project. These are both feedback loops. One starts and ends internal, the other starts and ends with the client. The longer the project takes the more times you have to go back to the client and re-assure them “No really, everything is fine“. The longer the loop the more work you need to do to maintain the status quo.

To make a bad analogy, look at DSL lines. You can only get them if you are close enough to the central office. Why? The signal dissipates after a certain length and it becomes unusable. It is lossy and long. Some ISPs have lengthened that distance by placing very expensive repeaters to lengthen the life of the signal. But it does not come without serious cost and there is still a limit on how far you can go. People are the same way. The signal dissipates the longer the loop goes on.

For some strange reason, manglement thinks that just pushing deadlines out further is a solution. But this only increases the feedback loop. It is why Scrum, by definition, will not go longer than a month – they realize anything longer requires way too much work to keep rolling. The solution is pushing the deadlines in closer, and only working on that one project until it is done. Don’t multi-task, focus on a single task. You will get more projects done over the span of a year doing it this way. And the clients would be happier, the projects would have less issues, and your teams would get along better (since these are the things that really matter here).

On Application Design

Jim and I were talking about how to correctly design an application, but from the people and process point of view – not the technology. Here are some assumptions we have walking into it:

• Division of Labor: you have different people doing the client-side work than the server-side work. Designers shouldn’t program, and programmers shouldn’t design. Just like stakeholders shouldn’t architect or design, and architects shouldn’t be writing copy.
• Working in Parallel: you don’t want someone sitting around waiting for someone else to finish their job.
• Don’t waste time: you don’t want everyone burdened down with reading, comprehending, and updating documentation. If the application cannot tell you what is happening you have a larger problem.
• You have more than 5 people working on it: you can’t schedule a three hour meeting that includes choosing what features, how you’re going to design those features, and how you’re going to implement those features together. Chances are, at best, one-third of the people in the room care about any one of those. You’re wasting their time if they are there.

Choose the Features

Get your stakeholders together and choose the features you need to accomplish. I don’t care if you put stickies on the wall and do pin the tail on the donkey. I don’t care if you throw darts at a dartboard. I don’t care if you’ve asked your users. The stakeholders are the ones who have something to lose, the ones putting their companies and reputations on the line. They are responsible for making these decisions. Keep in mind. These are features. Requirements. They are not use cases. They are not mockups. They are not movement through the application. They are not step1, step2, step3. They are the raw, and unpolished needs to make money. The stakeholders will not design your product – that is not their job. Your CTO will not design your product, that is not their job.

Design the Features

Your implementation team can go and draw up the tables, make the O-R mapping objects, and make some simple skeletons that they can test with. They can also write some unit tests, business validation, and whatever abstraction they need. They can do all of this without any design whatsoever.

Your client-side team can make mockups. These mockups will be in the native environment. We work on the web. That means these mockups will be in HTML, CSS, and Javascript. They will not be in photoshop. Don’t waste your time designing something you cannot implement. Design in the native environment. These mockups are the application at this point. Don’t design things that are not in the requirements. Go get buy-in from the stakeholders. When you’re with them make their requested changes immediately in front of them. If you’re good, and have a good framework to work with, this will not be hard. Get buy-in. Then go user test these mockups. Get the kinks worked out.

Split out the features among all your people. No one should be over-burdened. Play to their strengths. Once you give a feature to someone – they own it. It is theirs. The stakeholder can’t tell them how to do it. The designer can’t tell them how to implement it. The coder can’t tell the designer how to design it. If you are not writing the code – you do not get to make the decision.

Integrate

Once the kinks are worked out, the client-side team gives their HTML mockups to the implementation team. Any integration kinks can get ironed out – but there should be few if there requirements were clear. This is the end of iteration #1. If the requirements were not clear – go back to the requirements. Forget the design.

Do It Again

Hopefully you can release this pronto. It doesn’t matter if you have users. Get it through QA. Get it released to a server somewhere else. Get some closure. Stamp done on it. Move on. Then start at the top with your stakeholders – what is next.

Problems You Are Going To Run Into

• The requirements won’t be understood precisely by everyone in the same way. Expect it. And go back to the stakeholders when this happens.
• Integration and QA should be two thirds the time spent on a given project. In most respectable shops, QA is double the development time. Expect half the development time to be Integration.
• Problems caught earlier cost less, in both time and money, to fix. Catch them when you are dealing with HTML on the client side. Catch them in unit tests on the implementation side. Deal only with integration issues when you are integrating. Get all your functional stuff out of the way when you are working alone.
• No one is perfect, plan for it.

On Teams

Over the course of my life I’ve been on more than a few teams. Sports teams, work teams, programming teams, church teams, and student teams. In more than a few ways they are incredibly similar. Almost shocking how similar. There is an enormous amount of research done on teams as well, so much I don’t even know where to start with it. Leadership and teams are how the world works – seems only fit to study it. The single most important factor that I have ever experienced is respect.

The times that I have felt my team succeed (regardless of how well they accomplished, or did not accomplish, the external goal) have been because of respect. Everyone recognizing that each person in the group – while perhaps not equal – all play a role. They all have a spot. Everyone stays within their spot. They don’t strive to be something they are not. They speak when they need to speak. They are silent when they need to be silent. They strive to meet the groups expectations because they are lofty and correct. The group enforces right behavior and conduct. I don’t care if that is the programming culture of the group making you avoid the dumb things we’re going to have to cleanup later, or the clubhouse of the baseball team keeping you in line with your teammates. It is the expectation of every member, by every member to live up to what the group has chosen.

The times that I have felt that I have failed a group are primarily because I never found a spot. I was not able to figure out when to talk, and when to be silent. I did not know the group’s culture. Or my culture was different than the group and neither was being upheld. Failure, when it comes down to it, is a lack of communication. I am granting the fact that everyone in the group is capable and motivated. The only problem after that is communication. Unfortunately it is a stupid problem to have.

When people breach their group-given role, it can get real bad. When a leader, who is given that leadership position by the group (which is the only real way you get a leadership position), steps outside the group’s accepted behavior it is all over. They are no longer a leader. It doesn’t matter if they have the ‘Manager’ title, or the Captain’s ‘C’ on their jersey. Their decisions will be questioned, challenged, and possibly ignored. It is hard for a leader to recover from some of these issues. Which is why star players get traded all the time.

I feel that I am going through this is more than a few areas of life. Trying to be a leader for some, a role-player for others. All the while trying to figure out the unstated group culture. Politics is hard.

Architecture Astronauts

I don’t think I’m ever going to understand the position of the astronauts, or how they think. Of course, I don’t expect anyone to understand how I think without explaining myself. This might get very ranty. But their perceived solution to a problem (that they, sometimes, do not understand) is often the baseline to start arguing about the real solution.

Right now we’ve got a doozy of a problem trying to integrate Javascript into our framework. The fundamental issue is a bad perception of what Javascript really is, and what it is to do it correctly. Yes there are many approaches, and “good enough” ways to do things. Sometimes “good enough” is exactly what you want. But an arbitrary decision to have everything split up and organized into a certain way “because that is what makes sense”, or “is the right way” just betrays all sorts of bias.

Javascript is a very loose and fluid language – very unlike many other standard programming languages. And when you add javascript with HTML you have a very strange concoction. There is HTML that is written for the design of the page. And there is HTML that is written to show data. If you believe that these two types of HTML are written the same – you clearly haven’t done either for very long. If you don’t understand why writing semantic HTML (when displaying data, primarily) is important the likely-hood you don’t understand Javascript is very high.

Quote

People often get more abuse than they deserve because they are so often put in a position where no one notives them when they do something right, but they get blamed out of proportion when things go wrong.