Pete On Software

RSS Feed

Archive for 'Business of Software'

Programming is Not a Zero Sum Game

Zero Sum GameSimply put, a Zero Sum Game is a situation where in order for one person to win, another person has to lose. Or, in order for someone to gain something, someone has to lose that thing. Think about poker. In order for you to increase your chips, you have to win them from the other players, decreasing their earnings. At the tournament level, the game ends when one player has everything and everyone else has nothing.

It seems that a lot of people try to treat programming/technology like that. I know the counter argument to that is that I’m blind and crazy. Haven’t I seen blogs and been to conferences and user groups? People are sharing knowledge all of the time. That is true and that is great. Unfortunately, those people aren’t even close to the majority of developers. The majority are the Dark Matter Developers, and they are what is out there*. Additionally, this kind of selfish behavior I’m describing has shown itself to be human nature in all areas of the workplace.

No matter what the industry, people are often reluctant to share knowledge with others. Sometimes they are afraid that if someone else knows how to do “their thing”, that they will be easily replaced by someone else – probably someone else making less. The key is that if you can be replaced over one or two things, you have larger issues. If someone else knows how to do the thing that you are holding on to, that frees you up to learn something else and grow your skills and your worth to the organization. If nothing else, the act of teaching something to another person will build your own “instruction skill”. Being willing to always teach others also makes you more valuable to your employer because it shows that you are a team player.

Besides job insecurities, another thing that will keep developers from sharing their knowledge is that they like being the only one to know things. I’ve met several people that fit this bill and I’m ashamed to admit that 15 years ago, I fit this bill. This one is pure ego and sadly, our community is known for some very big egos. If you are holding on to knowledge because you like being the keeper of that knowledge, you need to let that go.

When you were first learning, someone had to teach you. Even if you were “self taught”, you most likely read manuals/documentation, books, blog posts, Stack Overflow, attended conferences, user groups, etc. Most people did not gain their entire technology education by hacking around and figuring out 100% of things for themselves and never learning from anyone. I would wager money that if such a person existed, their code would be full of bugs, security holes, and performance issues because they’ve never learned what hundreds of thousands of “thought hours” have worked through.

If you learned from someone, teach someone else. Pay it forward. Pass it on. Give back. Mentor someone. Whatever you need to hear to get you motivated, hear it and act. Helping others ultimately helps you. If you’ll allow me one last cliche, “a rising tide lifts all boats”.

* Incidentally, I realize that this post may very well be preaching to the choir, since these Dark Matter Developers would probably not be reading this. My hope is that this post can be instructive, or at least serve as a reminder as you are out in the world to help recognize your own bias as well as the biases of those around you.

That’s Why They Hired You

Frustration!I think that we’ve all been to the place of being frustrated at work. There are lots of sources of frustration, but today I want to talk about a specific kind of situation.

If you’ve ever been a consultant – either for yourself or others – you may have gotten the chance to work on a large project rather than a staff augmentation role. There are basically two reasons that a company would hire a consulting company to tackle a project for them. Either their plate is too full to perform the strategic work or they do not have the proficiencies in their staff to tackle the project. Honestly, most interesting projects fall into that latter category. And *that* is what I want to talk about today.

To win the project, you probably responded to an RFP and you had to demonstrate your experience and proficiencies with the technologies at hand. You may have had to be interviewed and show prior work, proving that you didn’t just Google the thing on the way over. Basically, you are the closest thing to an expert in this area that the company has contact with. Since you are the chosen one, you should be able to just come in there and do your thing, right? Surely, they won’t have any opinions on technologies that they are entirely unfamiliar with?

Of course not and of course they do.

I’ve been on a few projects where the consulting company was brining entirely new expertise into an organization. That never stopped that organization from asking questions… and they should ask questions. Where the frustration arises is when you make a thoughtful and careful decision, write a recommendation showing why you went that way and you still have to defend it. Not against solid questions that you forgot or didn’t think to address in your recommendation, but questions that come about because someone with a lofty title Googled “{insert technology} sucks” and just read you objections to the technology.

Those discussions can be fun, but not when the antagonist can never take the discussion beyond the surface because that’s all of the research that they put into the topic. Here is an absurd (made up) example of what I mean:

Sample Conversation:

Them: “Why don’t you use MongoDB, I heard it was Web Scale?”
Me: “The requirements call for this application to be used by your accounting department, which consists of 8 people.”
Them: “But, what if we want to put this in the Cloud to make it Web Scale?”
Me: “None of your systems that this needs to talk to are Internet-facing and you have a corporate restriction against having point-to-point VPN connections with machines that you don’t control or machines that aren’t in CISP certified data centers.”
Them: “Fine, why can’t we run MongoDB locally.”
Me: “You could, but your entire organization runs on Oracle. Why wouldn’t we just put the 3 tables we need into your existing database, saving costs, implementation time, etc etc?”
Them: “I don’t understand why kind of consultant you are if you are if you are afraid of modern technology.”

And… scene.

Fortunately, I haven’t had exactly that conversation, but I’ve had some conversations that make about that much sense and have been accused of worse. It is very easy to get frustrated at that point. But, I’ve found that it is best to take a step back when this happens. Why are you expecting them to ask you questions like they are an expert when they brought you in to be an expert? They are asking questions about an unknown thing because they are curious, or because their butt is on the line if you mess up, or just because they want to do “due diligence”.

Remember, if they already knew all of the answers, they wouldn’t have needed you. They would have set their own direction and if they were understaffed, they would have just gotten some warm bodies to meet demand. Instead, they hired you for your expertise, so try to remember that during your discussions and explanations.

Bonus tip: For the love of all things, don’t be condescending in your discussions. You might say, “Of course”, but I can promise you that it happens and many times it was not your intention. Guard your words and your attitudes and you’ll be appreciated.

Time to Leave Your Job?

The Future Awaits - from
An article was posted over at Mashable titled 8 Signs It’s Time to Leave Your Job. I can see their perpective on all of their points, but to me their 8th point was the main point.

You are no longer passionate about your work and dread going to the office each day.

That is my number one criteria for looking for new employment. Do I dread going into work? Am I excited about the kinds of things that I get to do at my job? Not every day is a mountaintop, but if you have a prolonged period of dreading work, then you should consider moving on. All of the other points roll into that one. They talk about politics and high profile work, etc. Different strokes for different folks and some people aren’t affected by the same things that affect others. It all comes down to whether or not you die a little inside when the alarm goes off in the morning.

Assuming that you’re getting paid basically what you can make elsewhere (give or take a few percent) and that your benefits are fine, the only other consideration in my mind is whether or not your skills are being allowed to grow, or whether they are stagnating.

For example, if you are a .Net developer and your workplace is still working on the .Net Framework 2.0 and you are only using Web Forms and you are on SQL Server 2000 with no chance of an upgrade, you should think about going even if you are happy. Your alternative is to get very involved in “new technologies” in your spare time so that you don’t become easily expendable.

The days of working somewhere for 40 years and retiring with a gold watch and a pension are basically extinct. If you allow a job to manage your career for you, you will find a time where it is 2013 and you are looking for work and you have been doing FoxPro 6 or Classic ASP for 15 years and now you can’t find a job that will pay you anywhere near what you need to support yourself and possibly a family.

So it is all summed up very simply as to whether or not you like going to work every day. If you love the place and it is feeding your career, then you already know that you shouldn’t be looking anywhere else.

If you love the place and it is strangling your career, consider whether or not you have the time or inclination to put in the work “off hours” in a very big way to gain the requisite experience in “new technologies” that you may or may not use professionally. If you don’t have that time or inclination, look to move on, even if you love your job.

If you don’t love waking up in the morning to go to work, get out. Life is too short for almost anything else to matter.

A Mobile Strategy?

Harvard Business Review published an article at the end of last month titled Building a Mobile App Is Not a Mobile Strategy. The TL;DR; version is that mobile is not an item to be marked off of a checklist. It is bad if your company just created a mobile app so that you can answer “yes” when the CEO asks, “Do we do mobile?”.

I heard someone speak at a conference here in Ohio who was making this same point. Some time ago, the best visual medium for advertising was the print ad. Since that was the end of the standard understanding, when the web came about, people set out to put up what we now call “brochureware”. Basically taking their magazine ad or brochure and putting it up on the web. No real interaction and no reason to ever have a repeat visitor. Hey, but at least they had an “Internet Strategy”, right?

The same thing is happening now. Mobile is hot, so people are trying to create mobile apps that are nothing more than advertisements or brochureware for their product or business. Not a lot of people “get” mobile yet, so the good ideas are coming slowly. However, just as companies began to create interactive websites that provided a service or amusement while educating or advertising their service, that time will arrive for mobile, too.

Sit or SquatEven now, forward thinking companies are getting it. The article mentions Proctor and Gamble’s sponsorship of a 3rd party application called “Sit or Squat” that helps locate public restrooms wherever you are, while at the same time keeping Charmin at the forefront of your mind and associating it with the best possible restroom experiences.

Having an idea or a strategy for what you will do to “accomplish” mobile is great, but the Harvard Business Review article pretty much stops there. In my opinion, the key to having a dynamic and impactful mobile strategy isn’t just how you will market to consumers. It encompasses how your employees will be productive. What sorts of applications could your employees use “on the go” (in meetings, during travel, etc) on a smartphone or tablet device? How will you deliver those applications to them?

The other big key to a successful mobile strategy is integration with your existing business platform. What sorts of services or APIs does your organization have exposed to allow mobile applications to integrate with your systems? If you have none, what would it take to create them? This to me is the heart of a Great Mobile Strategy in the Enterprise. It is mobile as an integrated natural evolution of your systems in a way that encourages productivity and growth. And that is the hard part.

If you aren’t in a place where new applications can integrate with you, then you are in a place that is stagnant. If every new application has to tear down and throw away what came before it, you are asking to fall behind. A Great Mobile Strategy starts with a Great Overall IT Strategy that allows mobile to become not just something “checked off” or “bolted on” but a full-fledged member of your company’s application stack.


'Overtime' from
A while back, I read a blog post on Big Bang Technology’s blog written by Max Cameron titled “Why We Don’t Work Overtime“. I will give a full disclaimer here at the outset, I probably work too many hours, so I have a little bit of skin in this game. Namely, I could be accused of only responding because my work choices were being invalidated by someone else. That certainly isn’t my impetus for this blog. I merely wanted to offer a different perspective to Max Cameron’s blog post.

Cameron is writing from the perspective of a Startup Company. He does make an exception to the overtime rule for the founders, but for his employees he says,

There are no heroes at our office. When the clock strikes five, 
the team goes home. If they try to keep working, I tell them that 
the game's over and they lost. They either put too much on their 
plate, got taken off-task, or were wasting time. None of those 
justify working past five, on a holiday, or over a weekend.

I certainly applaud his motiviations. He sticks to this rule even when clients ask for it, when they’d need it to win new business, etc. It is one of his company’s core values and they stick to it. Everyone realizes that when an employee (especially a salaried one) works overtime, he is “doing more than he agreed to” and is “taking away family time” and “upsetting the work/life balance”. However, what I find interesting are some of the reasons that their company takes that choice away from their employees.

One major reason that Cameron cites is that to persuade employees to work overtime, the noble concept of “sacrifice” is invoked. In his mind, soldiers, firefighters, and police officers sacrifice, and to try to align that concept with “expected overtime” is a dangerous habit to get in to.

He points out that the employees who work over are the “heroes” and those who don’t are “losers who let you down”. In his words, “Yearly reviews just got a whole lot easier”. Later he says, “How could I promote a loser when they’re surrounded by winners?”.

I want to deal with that point first. He is obviously being rhetorical and a little sarcastic with those last quotes, arguing his point to ad absurdum. However, I think there is a point to be investigated there. My current boss has taught me a lot about managing people and the value of making “the hard decision”. It sounds to me like Cameron is welching a little bit on managing employees. Sometimes, you have to make the hard choices. As my boss likes to say, “Who do we pay to do the hard stuff?”.

Imagine on one hand that you have an employee who works only 40 hours and is very productive, gets along well with others, is a leader, and so on. Now, imagine you have another employee who works a ton of overtime, but you know that it is because he isn’t very efficient. He has a good work ethic and to make up for his lack of efficiency (and “social time” during work hours), he tries to even it out with that overtime. Now, if you are a manager who can’t promote Mr. Productive Forty and explain to Mr. Compensating why he didn’t get the job, you aren’t much of a manager and should rethink your career path.

Let’s pretend there is another scenerio. This time, you have two very equal employees. One of them is a “5:01 Developer” (gone by 5:01 every day) and the other works over to make sure things get done on time, or to add special features off of the “nice to have” list that never gets prioritized ahead of “big projects”. In that case – all else being equal – why wouldn’t you promote the overtime guy?

These kinds of decisions are why you are the person writing the reviews.

A point that Cameron makes alongside this one is the concept of burnout. This is definitely a very real problem. However, I feel that he’s again arguing to take the “copout” path. He seems to be claiming that it is impossible or would require too much work to monitor and make sure that his employees aren’t burning out. There is a big difference between running a guy at 80+ hours a week for months at a time, working 1 or 2 60-70+ hour weeks before huge release, and regulary working 50 hours a week because that’s what you are comfortable working.

As I admitted earlier, I definitely work overtime. I am soon taking my first vacation week in years (only because the company stopped paying out for unused time – I have to “use it or lose it” and I’m too practical for that ;) ). However, I’ve been going at this pace for about five years straight now, across 2 companies. I’m not close to burnout. You can’t manage people homogeneously, you have to manage to the individual. I’m more of a sports car, not a minivan, there is no danger of running the engine at a little bit higher speeds.

I’m not bragging. My point is that I’m different than other people and a team needs all kinds of people on it. The Apostle Paul actually writes to this point quite eloquently in the Bible in 1 Corinthians 12:14-21:

Even so the body is not made up of one part but of many.
Now if the foot should say, "Because I am not a hand, 
I do not belong to the body," it would not for that reason 
stop being part of the body. And if the ear should say, 
"Because I am not an eye, I do not belong to the body," it 
would not for that reason stop being part of the body. 

If the whole body were an eye, where would the sense of hearing be? 
If the whole body were an ear, where would the sense of smell be? 
But in fact God has placed the parts in the body, every one of 
them, just as he wanted them to be. If they were all one part, 
where would the body be? As it is, there are many parts, but one body.

The eye cannot say to the hand, "I don't need you!" And the head 
cannot say to the feet, "I don't need you!" 

There are things I do well and things that I don’t do well, and I realize that I don’t always see them clearly. The way that that is remedied is that my team is made up of all sorts of people. The person building the team knows what he has, and fills the gaps appropriately. The fact that I can easily work 50 hours a week or more without burning out is just a tool that my company has at its disposal, just as all of the other skills of employees are at their disposal.

One point that I just could not grasp in Cameron’s blog post was the fact that he is willing to let his clients down because of this overtime policy. Even if the work completed because of overtime would win their clients more business or help solve a serious problem that they are having, overtime is still off limits.

I see nothing wrong with working over to win new business, for you or for one of your clients. Your client has likely worked with others who cannot deliver these things and you make yourself indispensible to him as someone who can deliver them. But again, there is the potential for abuse, but that relies on your client service managers or account representitives to “do the hard stuff” of recognizing and stopping abuse before it gets anywhere.

As I was discussing this topic with a good friend of mine, he pointed out to me that one problem he had with overtime was that it “excused” or “covered up” poor planning. For instance, if a project was projected to have 15 features and be delivered in 2 months, but was estimated poorly, that can be a problem. Proper Agile philosophy is to have the business either extend the date based on the metrics from the iterations, or cut features. Another approach is for it to still spend the hours, but spend them in 60, 70, or 80 hour weeks to meet the deadline. That’s a “death march” and no one really wants that.

However, sometimes it is politically expedient to deliver the project by working the overtime. Not everyone works at a company that can afford to turn down external clients or at a consultancy that can easily refuse work. A good deal of software development is done as part of an “in-house” shop that develops software for “an enterprise”. There are 100 ways that you can curry favor by seemingly doing the impossible and those who don’t see the value in that don’t have a very mature view of the “real world”.

However, the issue then comes if you don’t learn a lesson about your estimating and back yourself into those kinds of corners on project after project. Again, I fall back on “Who do we get to do the hard stuff?” If your Project Managers can’t control these projects from the outset, you probably have the wrong people in there.

This has definitely been one of my longer rants and I know that a lot of people will disagree with me. Feel free to leave a comment below, or blog your own responses. If you do a reaction blog, please link it in the comments so that I can read the discourse and the other readers may benefit, as well.

« Older Entries   Recent Entries »