{codesqueeze} » Human Factors

Marketing Ideas To Help Sell Your Ideas (Sam’s Club Cup Pt. 2)

Max Pool — Thu, 07 May 2009 08:56:28 +0000

In my previous video – Features Do Not Exist (Only Benefits), I went on a bit of a ramble about how a cup got me all wound up. Well, the cup is back but this time with much better wording:

When choosing a foam cup over paper or plastic, we considered the environmental impact of raw materials, manufacturing, shipping and disposal. We believe we have made the most responsible decision but we’re in search of an even better alternative, If you have a viable, alternative option with a smaller environmental foot print, please email your idea to cafecup@samsclub.com. Together, we can create a more sustainable Sam’s Club.

Lesson learned – wording is everything.

Similar Posts:

[Advertisement] - Atlassian provides zero-friction bug tracking and continuous integration solutions for software development teams. Visit Atlassian for free 30 day product trials.

If You Aren’t The Caretaker, Why Are You The Product Owner?

Max Pool — Mon, 27 Apr 2009 07:57:22 +0000

Agile and Scrum has done a horrible and irreversible injustice on software culture with it’s term – Product Owner.

The definition of Product Owner straight from Mountain Goat:

The Product Owner (typically someone from a Marketing role or a key user in internal development) prioritizes the Product Backlog.

Scrrrreech. Repeat that? Don’t see the problem yet? There are really two pieces here, so let me explain.

The first flaw is in the semantics of the word – owner.

owner: to have or hold as one’s own; possess – Dictionary.com

In short, we have mislabeled this role to begin with. The person who “owns” the product (i.e. the business, a CEO, or in Mountain Goat’s definition some Marketing role) is more appropriately the person who has financially paid for and owns all legal rights to the software. I would wager that 99% of software projects are not consumed by the legal owner of the end product, but by a subordinate.

This leads me directly to my next point [that I find it ironic] the term Product Owner has become synonymous with the role of being the person who is responsible for the delivery of the product. In most cases, this is the true legal owner (or someone who is very accountable for the time and money spent).

So here is the big question: Product Owners are not responsible for the long-term care and usage of it, so why are they in charge of the delivery of it?

Contextually, it is absolutely no different than a father who test drove, purchased, and owns a car he bought for his child with only a small amount of verbal input. From a salesman perspective, I want to know what the father says, but as an engineer I want to know what the child wants! Adding salt to the wound, we now have processes centered around a social antipattern which are appropriately mislabeled.

In all reality, I know we will never be able to break the habit of the people accountable for the project budget wanting to be involved in the process. They need to receive a false sense of assurance that the software will delivered and they will get what they paid for. However, I do believe by correctly labeling the most active role to something more representative of the person we want to engage in a meaningful client relationship with, we can reverse the trend of placing so much emphasis on the “when” and more on the “what” and for “who”.

Similar Posts:

[Advertisement] - Atlassian provides zero-friction bug tracking and continuous integration solutions for software development teams. Visit Atlassian for free 30 day product trials.

Companies Aren’t Progressive (But People Are…)

Max Pool — Mon, 06 Apr 2009 07:49:30 +0000

Something was recently said to me that struck a small nerve:

You know Max, one thing you don’t get is that you have worked for a ton of progressive and agile companies. There are tons of developers stuck in crappy process and code working for companies that just will never get it…

Although it would be a company’s best interest to be involved in process improvements – is it really the responsibility of the company to invoke process improvements?

A business (in a nutshell) needs to concentrate on one thing – stability. With that realization many thing become apparent; however, for this argument hopefully it is clear that most [successful] companies will not make radical changes to the same processes and procedures that caused success in the first place.

Additionally, because most of the company employees are “so deep in the forest, they can’t see the trees” it is hard for most companies to see their inefficiencies. Even worse, some companies have identified their weaknesses and after years of inaction towards a solution have written off the inefficiencies as the cost of doing business.

With no reason backed with business value all companies will actually resist change. Therefore, it is your responsibility to start the change from within the company.

First off, you most understand the pain caused by the inefficiency, and therefore can best translate the relief of that pain with a given business value. Secondly, if not you then who? If you have enough courage to talk badly behind someones back, but can’t muster the courage to confront the problem, that makes you a coward. Nobody is going to fight your fights but you.

I have worked for some crappy companies, but I have never left a company without leaving it in a better place. The company didn’t change me, I brought the change with me.

Similar Posts:

[Advertisement] - Atlassian provides zero-friction bug tracking and continuous integration solutions for software development teams. Visit Atlassian for free 30 day product trials.

Frustrated With Coworkers? The Clue You Don’t Want To Hear…

Max Pool — Mon, 19 Jan 2009 07:24:10 +0000

Being frustrated with your coworkers from time-to-time is not unique to any single occupation or person. Everyone has days where they want to severely hurt the person in the next cube. The question that begs to be answered: What drives us to these feelings?

The obvious answer that everyone would like to shout at the top of their lungs is – The Other Person Is Being An Idiot!!!. Although this maybe the case, why does it bother you so much? Why not chuckle at the poor fool and move along with your day? It is my belief that there are 3 core reasons why, but the last one you might not be ready to hear…

They Have A Passionate Personality

A lot of people I know are insanely passionate about what they do to a fault (this includes myself). As a common result, communication with insanely passionate folks tend take on a feeling of almost arguing. As the saying goes:

…this is good, now that we are arguing we are finally talking…

Unfortunately, both passionate and lesser passionate coworkers will always perceive the other person as being blunt, stubborn, or even a verbal bully. Your understanding of this personality type might ease the pain when having to deal with them as you can concentrate more on what they are attempting to say rather than how they are saying it.

Everyone Takes Personal Pride

Even including the most apathetic people that did sloppy work, I have never found someone that did not take some amount of personal pride in their work. This is especially true for our occupation since developers have a sense of “creation” in their work.

Where pride comes into play is not so much “who” you are talking with but more “what” the topic is about. If you are discussing a found bug, is there friction in the conversation because it occurred in your code? Is the other person being defensive because it happened in their code? Are you both being combative because you disagree on the solution?

You do not need to be a developer to have personal or professional pride in your work; however, this rub point occurs a lot in our occupation considering every conversation we have deals with the intellectual creation of another.

You Don’t Get Along With Yourself

Here is the one you are not ready to hear. You can’t stand yourself. Trust me, it’s true.

If you hate a person, you hate something in him that is part of yourself. What isn’t part of ourselves doesn’t disturb us. – Hermann Hesse

Like personal types tend not to work well together. Believe it or not, you do need a good balance of personality types and ideas. However, this is a tough pill to swallow because we all suffer from the same delusion that a bunch of clones of yourself would work faster and more efficient than any other group of people.

Being in a frustrating situation with coworkers is only natural; however, how frustrated you get is directly related to how well you understand the situation. If you keep your cool and give yourself some time to really analyze the situation, I bet you will find a very predictable human reaction behind it.

Similar Posts:

[Advertisement] - Atlassian provides zero-friction bug tracking and continuous integration solutions for software development teams. Visit Atlassian for free 30 day product trials.

The Wisdom Of Insecurity

Max Pool — Wed, 03 Dec 2008 07:00:55 +0000

In theory, with experience comes wisdom, but what are the results of that wisdom?

Better technical decisions? Sure.
Better communication skills? Why not.
More confidence? Never.

One of the greatest gifts my experiences have given me is the gift – insecurity. I have learned not to assume a refactor will be easy. I have learned not to optimistically estimate. I have learned NOT to allow the first possible solution be the only explored solution to a problem.

One of my favorite authors, Alan Watts, wrote a book called The Wisdom of Insecurity which talked about why it is good to question organized religion. It is not my point to argue religion in these thoughts; rather give accreditation to the practice of insecurity.

Developer pitfalls such as underestimation, short sightedness, and buggy software can all be avoided with the practice of insecurity, and avoiding pitfalls is the first sign of a wiser developer.

Similar Posts:

[Advertisement] - Atlassian provides zero-friction bug tracking and continuous integration solutions for software development teams. Visit Atlassian for free 30 day product trials.

What Fraggle Rock Can Teach You About The Art Of Letting Go

Max Pool — Mon, 01 Dec 2008 07:57:40 +0000

Disclaimer – Before I really start brain dumping, let me be honest – this post might turn out to be hypocritical. It would be nice to think that with profound experience I am wiser and can understand how the moving nature of software works; however, I also realize that I am getting older which results in the growing problem of stubbornness and a general distaste for change. Alright, now let’s talk about Fraggles and software…

The need for clients to change direction on projects is a necessary evil to our profession. Without being able to iteratively see and touch the solutions we are building, they do not have the insight to make the correct decisions on the direction the project needs to take. However, it is these corrections that set software development back, that is, the constant rework that occurs when assumptions and constants change.

Thus far, the only constant I can assume is the constant of change, and how you deal with ongoing project changes speaks volumes of how far along you are in understanding this constant. If my warped mind was to come up with some evolutionary chart of attitude towards project change it would be something like this:

1. You Think You Know Better

The first phase of any fresh young developer is going to be the one of ignorance. Just because you can wrap your mind around a particular domain or problem, you will instinctively feel that you know more about the solution space than everyone around you.

Of course, this is a general lack of humility and humbleness. The people you are working under are probably smart people, and even though they may not know what they want or are generally bad at articulating thoughts does not imply they don’t understand their domain.

2. You Assume The Client Knows Better

In time, you will probably get your ass chewed out for overstepping your boundaries. This is when a little humility sets in and you attempt to open your ears with the assumption that the client knows better.

Now I know that 2 sentences ago I said that you work with smart people…well…this may not be the case. At this point, at least we are listening to the clients problems to gain a deeper understanding of the domain and its problems.

3. You Know You Know Better

At this point of your career, you understand the problem domain pretty well. You understand the ins-and-outs of the business and can make real contributions. The problem during this phase is that you get extremely pissed off when your solution starts to become the result of community solutions (caused by stakeholders need to feel important)

When projects take sharp left, right, and 180 degree turns, you somehow feel that it is your responsibility to either contribute a large amount of hours fixing the solution or argue your why out of the change. Very few developers ever leave this stage due to the high level pride in ones work.

4. You Know Clients Pay The Bills

This is the stage where you quit looking at the granular level of code, and start looking at the business. You quickly realize that you had your head in the sand for some time now (or most likely in a dark basement office with a nice coffee maker).

Now you are much more concerned about the business aspects of decisions. Sales and feature bullet points become much more alluring as previous priorities such as software integrity slowly melt away. It truly is humbling to realize one’s own hypocrisies.

5. You No Longer Care (And Just Keep Building)

Finally in the end, you realize it is a big Catch-22 and you concentrate all your efforts on just getting things done. Both sales and software integrity become equally important but not as much as productivity. You realize you need all the puzzle pieces so you concentrate on getting as much done in both realms as possible regardless if the vision changes.

Here lies the Zen of the little Doozers in Fraggle Rock. Regardless of how much those bastard Fraggles munched on their crystal structures – they kept building. They did not bitch or moan, nor be agreeable or argue. They understand the nature of constant motion their little structures take; that is, that they need to stand firm but are expected to be torn down, moved, or changed.

This is exactly what software is – the constant of motion. Do not argue with it. Do not agree with it. Just breath it in and be it and be a Software Zen Master like the little Doozer.

Similar Posts:

[Advertisement] - Atlassian provides zero-friction bug tracking and continuous integration solutions for software development teams. Visit Atlassian for free 30 day product trials.

Why New Developers Should Consider Contracting

Max Pool — Wed, 22 Oct 2008 12:14:59 +0000

A lot of young and talented developers are continually looking for new projects and problems to solve and gain experience with; however, there are very few single environments that provide the ability to diversify and grow. Most jobs consist of working on legacy code where there is very little architectural “wiggle room”. As a result, many developers feel the need to move to a different job or environment to get to the next level of learning.

While job hopping is one way to gain diversified experience, may I offer an alternative – contract work.

In hindsight, one of the fastest ways I matured as a software developer was through the experiences I had while working with a consulting company. Why is this? A few reasons:

Many New Projects (And A Few Old Ones)

Opportunity for a diversified workload is probably the biggest reason contract work is a great environment for learning. The opportunities for new projects and clients come fast and furious. In fact, in my experience I rarely was on a single project for more than 6 months (and even then, I was working on different client projects on the side).

The ability to start with a clean slate every 2-3 months is priceless. I always joke that the only code I am proud of I wrote less than 6 months ago. It’s for this exact reason, I got in the habit that I got to learn from every project mistake and continually get better.

Old projects exist as well (and this is OK) as it allows for developers to also learn how to maintain legacy systems. Brainstorming how to introduce unit tests into a Lotus Notes application can be a very daunting (but rewarding) task. Not every project gets a clean slate at the end, which is a great equalizer in terms of learning to write maintainable code.

Different Problem Domains

With different projects comes different problem domains. It is insanely fun to be building a restaurant’s blog, then to go to a meeting about blood pressure machines, and finish the day off with learning about retirement funds. Don’t get me wrong – it can be exhausting…but it is enlightening.

Probably one of the coolest domains I ever worked in was I had the opportunity to write an application that physically moved a HUGE dirt shovel for a coal mining facility. What an awesome domain! Physically coding with a hard hat on, in the middle of a strip mine, and my code is moving a 2000 ton machine around – can I get a hell ya?!? These opportunities do not present themselves often if you work for a company solely focused on one business domain.

Architectural Responsibilities

In most consulting shops, you are the lead developer, architect, and tester. Although being your own tester sucks, the trade off of being your architect provides unbelievable experience opportunities to implement the patterns and architectures you see fit.

Probably the hardest thing to gain is wisdom and insight of architecture. When to use them, when not to use them, when to use them but then break them. Different projects, different domains, and the responsibility to pull it all together provides the opportunity to gain this experience quicker than most job environments.

Learning To Deal With People

With consulting comes dealing with clients. Thankfully, I never had to deal with any assholes, but communicating with people is a skill that takes a lifetime to learn. If you do not learn how to talk to clients, you probably also don’t know how to talk to your boss, manager, or even spouse. Consulting forces you out of your dark corner, even if it is just in small doses.

Being a consultant is what you make of it. If you decide to be a hermit that never talks to clients and always decide to solve different problems with the same solution, you probably will not learn a lot. If you decide to sharpen your skills as a communicator while experimenting with different technologies, patterns, and architectures consulting might just be a good fit….

Similar Posts:

[Advertisement] - Atlassian provides zero-friction bug tracking and continuous integration solutions for software development teams. Visit Atlassian for free 30 day product trials.

What America’s Got Talent Can Teach You About Managing

Max Pool — Mon, 06 Oct 2008 07:57:32 +0000

This is a reader guest post by Jeremy Neuharth. Jeremy is a .NET software engineer with State Bank and Trust and enjoys learning and assisting teams in implementing release management and continuous integration.

As an individual that watches the national talent completion America’s Got Talent I was surprised when I found something beyond basic entertainment value. What is this special nugget, well it is a management framework that should be used for managers everywhere.

What does America’s Got Talent have to do with management anyways? I’m so glad you asked! It is simple, really. I’ve broken it down into three parts, and think it is quite an effective process for managing employees.

1. Set expectations

When a performer comes out on stage, he knows he must wow the crowd and judges so he can continue on to the next round. Now, obviously on a TV show with thousands of performances one doesn’t have the same ratio of managers to employees, and for the most part the expectation is understood, but the thing to note is an expectation has been set.

Likewise, I believe that generally most employees show up on the job with the desire to do good work. So, if expectations are communicated to them, they will work to achieve those goals. It is almost human nature to try to satisfy your boss, just as it once was to try to please your parents (if it still isn’t). Therefore, as a manager, you should clearly state what your expectation is for each employee so they are aware of their goals and can attempt to achieve them. Listen to the Hoff, make us go crazy from your performance.

2. Watch and “X” if needed (Coaching)

During each act, the judges (managers) watch the performance without getting involved, except in the case where the performance is failing. In this case, the judge “X”s the performance, which alerts the performer to the fact that he is not meeting the set expectation.

If a manager has set clear expectations, I believe a normal employee would not expect a manager do their work for them, but rather use your experience to coach from the sidelines. (NOTE: I said sidelines, which means that you can’t be on the playing field asking for updates every 10 minutes). If the employee runs off the tracks a bit, but has some experience with what he is doing, let him run with it – you might learn something yourself. On the other side, if that same employee is heading toward a total train wreck of a project, get in there and coach him to success.

3. Give feedback ( Punishment or Praise)

The third and final step of the model is giving feedback. Once the performer has completed the performance, each judge chimes in with how they felt the performance measured up to their expectations. If the performance was beyond their expectations they might give a standing ovation with words of praise to go along with their vote to the next round. If the performance needed small improvements they might give some advice and let them try to prove themselves in the next round. Finally if they missed the mark, not only are they punished verbally, but they lose the opportunity to perform again until next year.

The same applies to being a good manager. If, as an employee, I miss the mark, tell me what I did wrong and pull back the reigns a bit. If you can tell I learned the lesson and have gained valuable experience, let me go to the “next round” and show you that I have learned. If I really missed the mark, take me out of the competition for a while and coach me a bit to get better.

As you can see, America’s Got Talent has not only provided us with a few hours of entertainment, but also a management process that is simple yet effective. Unfortunately, an amazing number of managers fail to hit the mark. Apparent “mind reading” tricks and a tremendous lack of feedback have allowed ineffective workplaces to run rampant. Create an environment for your employees to use the talents you hired them for in the first place, and use the America’s Got Talent three easy step management system by setting expectations, monitoring, and providing feedback. Vote for your favorite, lines will be open for approximately two hours after the end of the show…

Similar Posts:

[Advertisement] - Atlassian provides zero-friction bug tracking and continuous integration solutions for software development teams. Visit Atlassian for free 30 day product trials.

Don’t Go For The Doughnut

Max Pool — Mon, 22 Sep 2008 01:23:06 +0000

Don’t get me wrong, getting a hi-five from your boss is a pretty cool feeling, and getting a gift card for Best Buy from your employer is pretty cool too; however, what I do find often are people that allow themselves to only be rewarded in this fashion. I call this “Going for the doughnut” effect, that is, people allow themselves to only be rewarded with the occasional box of doughnuts and never with meaningful or sincere awards.

For example, let me tell you a little story about a guy I know: This developer bleed for his project managers for 2 months putting in over 80 hours each week to reach a fictional deadline. When the smoke cleared he emerged victorious…which he was promptly awarded a $100 gift card to Best Buy.

Cool right? WRONG.

First off, let’s put this into perspective. 80+ hours a week * 8 weeks = 320 hours of overtime. The reward was $100 for 320 hours of overtime = $0.3125 per overtime hour.

To add injury to insult in this story, the very same day his boss announced they would be doubling the company Fantasy Football pot to a tune of $400.

Alright, so what are the three elementary lessons to be learned here for all managers and team leads? Anyone?

1. Rewarded overtime >= $1/hr

If you are going to reward your employees, be sure to reward them with gifts that at minimum equal to $1 / hr of overtime. AT MINIMUM! Two 80 hour work weeks would be very justifiable if at the end of it you got a $100 gift card for that expensive downtown $30 a plate restaurant for you and the spouse to take a night off and reconnect. That sounds pretty good right? What about an iPod Touch after a really long project – cool! Just remember that they value of the reward does need to be at least in the ball park of the sacrifice put forth by your employees.

However, probably the most appreciated of all gifts is reciprocal time off, even if it is at a lesser ratio of 1:1. Put in a 80 work week – take next Friday off. As an employer you have to be an idiot not to take these opportunities. As an employer you are trading 40 hours of work for 4 hours of downtime, that is ROI that you can not beat!

2. Fun budget < Reward Budget

This is absolutely critical but so many people get it wrong – always spend your extra budget to reward hard work before creating a culture of fun. Sure it is great to work at a place that likes to have fun, but they call it work for a reason. You want to keep the resources that are top producers, not the people who are loyal solely because the company is cool and fun.

Creating a culture of fun is extremely important in any company, but showing your employees that you are business first is mission critical.

3. Advocate Sane Hours

If you have read my blog for awhile you know that I sincerely attempt to advocate a 8-5 hour day. I too get hung up in the office a few extra hours, but permanent heroics are a sign of a weary team and bad management. Good management knows when developers need to temporarily bleed and when that emergency is nothing more than a out-of-whack expectation.

Similar Posts:

[Advertisement] - Atlassian provides zero-friction bug tracking and continuous integration solutions for software development teams. Visit Atlassian for free 30 day product trials.

Adding People To A Late Project Makes It Later

Max Pool — Wed, 10 Sep 2008 08:28:58 +0000

Hopefully, we have all come to the conclusion that adding people to a late project makes it later; however, I am surprised how many managers and developers still feel this is a good idea. One of my favorite quotable quotes is:

9 women do not make a baby in 1 month

I have talked before about balanced teams, but having correctly sized balanced teams is also important. If a team grows too large the overhead cost of communication, training, and coordination grows exponentially.

So what questions can we ask ourselves before adding additional resources onto a project?

Is this a temporary resource problem?

Many companies accidentally over staff themselves during situations where they legitimately need more people but on a temporary time frame. Adding permanent staff during these feeding frenzies is dangerous because the possible outcomes are never pretty:

Projects are overstaffed to “keep people busy”
Creates feast and famine experiences in work loads
Always in a hire-then-fire state (creates bad company blood)

What is the communication cost?

If we bring extra resources there are a number of questions we can ask about how we will weigh the cost of communication:

Will the people physically be in the office or remote?
Is our spoken language also their primary language?
What modes of communication are we limited to (email only, documents, phone…)?

Can we realign expectations?

In my eyes, this is how 90% of these temporary problems are solved.

Ask yourself, “Is this deadline really a deadline or just a made up one?” Unless your company has been running commercials announcing the deadline, it would be a good guess that this milestone or deadline is really just a fabricated placeholder in someones timeline. Can that expectation be moved slightly instead of asking for forgiveness when your late project become later.

How much time will we lose before we gain?

As the saying goes, “Two steps forward, one step back”, but in many cases ramp up time for additional resources is the first nail in the coffin for you project. There will always be a cost to new employees, so you can not always use it as an excuse not to bring on new blood – but is at the end of a project when you are the busiest the best time?

Be very leery when bringing people into a late project – it might just be the death of your project.

Similar Posts:

[Advertisement] - Atlassian provides zero-friction bug tracking and continuous integration solutions for software development teams. Visit Atlassian for free 30 day product trials.