Monthly Archives: January 2014

Why Building Software Is Not Like Building A House

Ok, I have had this conversation too many times to count. And depending on the social setting, I have argued it from both directions. (stick with me for a minute….) I truly believe that you can build software like you do construction. It can work. BUT I firmly believe that you should not do that. Not because its hard, but because we have an awesome opportunity with software to build something together with the business and not for the business. And that is the key difference.

Now, if I could build the house the way I build software, it would look something like this. I would put up four walls and a door and have the user come stand in the house. I would then ask “What else do you need?” They would give me feed back like “Its dark in here… maybe some lights?” I would go build the lights and windows, and the rest of their “needs” list and call that their “mvh” minimum viable house. Once I was done with that, I would walk them through the house and say, “Here is your house, move in today.” but I wouldn’t stop there” I would go on to say “now tell me everything you want in order of priority and I will add them one by one until you feel like we are done.” All the while, they can live in the house. Wouldn’t that be cool? Except, you can’t do that with a house. You can’t cheaply and affordably add lighting and windows and extra rooms on to a house after construction is complete. Or change the color of the cabinets or carpet. You can however do that in software.

The conversation always seems to go “you should be able to build software like construction” and the reality is you can. But, for me, the question is “Why would you conform yourself to a process that is restrictive and painful when there is a MUCH better way?” Building software gives us the opportunity to truly create something in a collaborative environment with everyone involved. Yes, you CAN do big up front design and estimation, and contract negotiation, or I can use that same time to build something usable that we can use to get test with actual real paying customers.

The paridime is different. Don’t conform to something just because it “seems” to work in other unrelated fields.

Who Are You?

Think about that question for a minute. If you had to describe yourself to someone (like maybe in an interview…), what would you say? We talk about brand management all the time when it comes to large corporations, but have you given much thought to your personal brand? When people think of you, what do you want them to think of?

Daniel Pink uses the question, “What is your sentence?” If you had to sum yourself up in one sentence, what would you say? For me, my sentence is this: “Jon builds and develops people and helps them to be the best they can be.” Thats what I do. Now, what is your sentence? Think about it.

Now that you have a sentence, that needs to permeate through everything you do until it becomes your brand. What you say about yourself is only part of the picture. Your brand includes what you do. For me, I run a consulting practice that mentors companies on software best practices, I coach kids basketball, I lead a cub scout den, I teach an adult sunday school class, I speak internationally on soft skills and process. Do you see a theme? Let me help, it has to do with the sentence I listed up above.

Lastly, use the resources available to you to make your brand clear. Linkedin, twitter, blogs, facebook should all be used to promote yourself. Perspective employers, partners, clients, etc, are looking you up on linkedin and twitter. Do they have a clear message about who you are and what type of person you are? They should. They are a fantastic free tool for you to use to promote yourself. Spend just a little bit of time on each to be sure your message is clear and concise.

Take 5 minutes right now and review your online presence. Does it paint the right picture of you? If not, fix it.

Can’t we all just get along?

Nothing is sure to sink a project more than fighting between the project team and all the other groups in the organization that it may impact. We have all seen this happen before, the project team needs something from infrastructure, security, or qa (although they should be on your project team…) and for whatever reason, they can’t or won’t help.

Now, I say “for whatever reason” to be inclusive but it is amazing to me how often we don’t take time to ask what the reason is. So it really turns into “for some reason they won’t concede to our demands….” Let me ask you a question, if an infrastructure team member came to you and started telling you how to write your app, would you listen? really? Yet for some reason as developers we tend to expect other teams to just do what we say or take our suggestions as gospel.

So, if you want to smooth the path with your neighbors, you need to do three things.

1) Get their input on your project early. Buy them donuts or coffee early in the project and tell them what you are doing and why you are doing it. Real reasons, not just that it is “the most important thing”

2) When they throw up a road block (and they will) take an honest interest in why they are doing it. Just because it is not important to you does not mean it is not important to them. Take the time to sit and understand their position. Not so you can convince them to change, but so you can find a solution that will work for everyone.

3) Make their life easier. Ask your project team what they can do to help ease the burden of these other teams. If qa is buried, can you do more pre testing? If infrastructure is busy, can you try automated deployments? Be creative.

Now, making their life easier only works if you took the time to understand their issues. Once you start treating these other groups like they are actual people with real issues and goals, you will be amazed how much easier it is to work with them.

tl;dr All the other people in your org are actual people, treat them like they are important and they know what they are doing…..

Don’t be “that” guy

OK, I know one thing for certain about whatever project you are working on right now. At some point, something will change. There is no doubt about it. You know it is true. Once the business owner or the user see something, they will want it be be different. Now, the question is, when that happens, what person are you going to be?

What do I mean by that? When something changes, there are generally 2 types of people that respond. There are helpful people who anticipate the change and work through what it means for the project. Or, there is “that” guy. “That” guy for whatever reason refuses to acknowledge that change is coming and when it does gets really mad about it. Generally the first response from “that” guy is “No! we can’t change it, why didn’t you plan?” or “It’s not possible to do that.”

Sometimes “that” guy takes the opposite stance. He will answer with something like “Sure we can change it, if you are willing to shut down everything and start over!” He will agree with a change with some overblown response in hopes that if he overstates what it will take the business side will back down.

These types of obstructionist people do nothing but add conflict to a project. So, don’t be “that” guy. But be careful, the pendulum can’t swing too far in the other direction. Some teams take whatever changes come there way and just go do them. Thats when you get into trouble with the business side not understanding why you keep missing the deadlines. They suggest changes, but are never told how that will impact their timeline.

So, what is the right way to handle this situation? You need to do three things with every change request.

  • Ask for time to review the change and estimate
  • Communicate as accurately as possible what it will take and how it will impact the project
  • Given an understanding of impact, ask what the priority is
  • Thats all there is to it. Every change, every time work these three steps. Following these steps in a helpful constructive way will add tons of credibility to you and the project team. It will amaze you how often a change is killed once the business side understands what a change will really take. It may also surprise you how many changes just are not that hard to do.

    tl;dr Things will change, be a voice of reason and calm in your organization. Don’t be the one who is looking to cause conflict.