Mike’s Dump

August 7, 2008

Agile Manifesto

Filed under: Work — mikesdump @ 9:02 pm

Manifesto for Agile Software Development

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

I found myself reading the agile manifesto today. I’ve read it before but today I felt the urge to read it again. Under normal circumstances I value the items on the left more than the right. But there have been times in my career where I have worked closer to the right trying to avoid being put in an unwinnable scenario. The sad reality is when this approach is taken you might be able to cover yourself/team but in the end is the customer really happy? In my experience the answer is generally no.

I love the first line in the manifesto. “Individuals and interactions over process and tools”. To me there is an underlying requirement not mentioned which is trust. I believe trust is the single most important ingredient in an agile team. I’ve always realized it was there but it has become clearer recently.

I’m not sure if it is the heat that does it to me or what (currently 32c in our house) but I just realized I blogged about trust last year around this time


July 31, 2007

Passion for Quality

Filed under: Work — mikesdump @ 3:11 pm

I get pissed off sometimes. Actually if you read my blog I get pissed off maybe more than I should. One thing that really gets me fired up is quality or to be more accurate a lack of quality.

I know very little about house painting. I do know when the job is done I don’t want it to be streaky, I don’t want my baseboards dripped on, and I don’t want my ceiling marked up. A professional that takes pride in their work wouldn’t need to be told this. A professional would realize that their reputation of producing quality work is worth far more than their current job.

I believe this applies to pretty much any profession. Professions that are regulated or have their work inspected afterwards are not exempt. If anything these professions have to maintain a minimum standard otherwise it is unlikely they will survive.

Now, look at the software industry. There is no regulatory body, nobody is going to revoke your “development license” and far too often the quick response is “why didn’t QA find it”? When I’m talking about software industry I’m not talking specifically about the quality of the code. I think there is a million and one posts related to improving code quality. In this case I’m only referring to what the customer sees because I have seen time-and-time again that documented requirements don’t work.

Ya, ya, ya, I know, “but developers make lousy testers because they test it the way they know it was implemented.” I’m sure we have all heard that one before and I’ll accept that to a certain point but again, consider any other profession.

Let’s consider a mechanic. Let’s say you took your car in to have the battery replaced because the car wouldn’t start. After the battery was changed wouldn’t you expect the mechanic to at least start the car before giving it back to you? If they didn’t do this very basic test to ensure your issue was resolved wouldn’t you start to question if you brought your vehicle to a professional? If you are the mechanic and said, “well I don’t know. I used that battery in another car and it worked fine”… not helping your cause.

Some might dress up otherwise but I still believe that developers are human. Everyone makes mistakes (I make a crap load!) and mistakes are a great learning opportunity. I believe the professional with a passion for quality will continue to learn from their mistakes, grow and earn a reputation for producing quality.

July 26, 2007


Filed under: Work — mikesdump @ 12:52 pm

Developers are a funny bunch. We normally applaud consistency but our world is anything but consistent. It seems everyday there is a new tool, library, or pattern hot off the presses that we have to try to incorporate into our toolbox. For some, this level of change keeps software development fun and exciting.

In most cases people don’t embrace change this easily. I have been thinking about a few changes over the years that have been more challenging than others. After reading this I believe I see why some attempts at change haven’t been as successful as anticipated. In some cases I believe what has lacked is “Being Vigilant” and “Acknowledging Success”.

I don’t think you need to beat people regularly to “Be Vigilant” but it is so easy for people to revert back to old habits. Speaking for myself I know at times I have fallen backwards. Some of the excuses I have told myself:

  1. I don’t have time
  2. It doesn’t apply it this case
  3. It won’t generate value
  4. I didn’t really buy in
  5. It’s too much work
  6. I forgot

Looking at my own excuse list it is pretty easy to see I’m not ready for “self-governance”.

Looking carefully at what “Being Vigilant” says I think sometimes we neglected to set a goal other than “to be better”. It is harder to acknowledge success when the success criterion is fuzzy. Maybe having clear goals could have made a difference or at very least made the journey easier.

July 24, 2007


Filed under: Work — mikesdump @ 12:02 pm

I read this post over at Slacker Manager the other day that really made me think. To get the context of this post you’ll have to go give it a read. It is ok, I’ll wait.

The culture of Blind Obedience

To get to the point, this culture really pisses me off. I hate most processes but having one rammed down my throat or being told to “just do it” really rubs me the wrong way. I think there will always be those people out there that take this approach but I won’t work for one.

The culture of Informed Acquiescence

I think I can say the majority of the jobs I have had in the software industry have fallen into this category. A number of times I have run into challenges working with other teams, not because they are being difficult but because they are working towards their own goals that may not align with mine. The problem here is not with one of the teams but both. An organization should be moving the same direction guided by a shared vision and objectives.

The culture of Self-governance

Ahhh self-governance, the perfect culture right? In theory I love it and that is where I want to be. I want to be in a position where I have the tools and authority so I can exceed expectations. This requires knowledge to be shared freely so informed decisions can be made by all which are guided by organizations goals.

But, and it is a big but. Would it work? Like most things in the workplace it boils down to the people you work with. Think about the people you work with now, would you want to give everyone the power that could make or break the project or the company?
I’m not discounting the newbie. I think everyone needs the chance to learn through their own experiences. I would have more trust in an eager newbie than someone that has a few years of experience but is completely task driven (i.e. needs to be told what task should be done after task A, B, and C).

Maybe I’m just not a very trusting person. Maybe it is just because I haven’t been a part of a self-governed culture. Maybe it has been just too damn hot and I’m grumpy but I’m not buying in that a pure self-governance culture would work in most cases.

What I believe the author of this post saying is the driving factor in these cultures is trust. Trust however, isn’t just being trustworthy; trust also includes trust of competency. You might have the most open an honest doctor but if your doctor tells you they feel faint every time they perform a surgery would you still trust them with your life? When there is a lack of trust you get more process.

Additional Process does not equal Addition Trust

Additional Process equals a poor substitute for trust.

March 21, 2007


Filed under: Work — mikesdump @ 1:32 pm

The past couple of days I have been in a few conversations around requirement documents. After giving it some thought it was time to do a brain dump.

What Do You Want?
I think what gets lost when more technical people write requirements documentation is what is required. Instead of focusing on the project from a user point of view they are thinking how they would implement the feature and write instructions instead of requirements

Create a table called customer to store customer information. The following fields should be stored . Write an after update trigger to capture any modifications in the customer_history table.

Is the above requirement wrong? No. But, does it really matter from a user point of view what the table is called? Does it have to be a database trigger for history tracking? Instead something simpler could have been written in the requirements document:

All fields on the customer screen (see screen shot) need to be saved. Anytime changes to the customer information are made a copy of the original information should be made so the changes over time can be viewed on the customer history screen (see screen shot).

You don’t have to be technical to communicate what you want an application to do the key is knowing what you want.

Screen Shots
A picture says a thousand words right? Seeing a drop down list beside a field called “salutation” right away would tell the developer that list of salutations is going to have to come from somewhere. This should bring up questions like:

  1. Does this list need to be modified by the user?
  2. Modified by administration staff?
  3. Or never modified?

Seeing this could mean creating supporting screens, tables, or simply hard-coding the values. Only seeing in writing the requirement for a field called salutation could be easily overlooked and created as a text box instead of a drop down.

Test Scenarios
Adding what scenarios are going to be tested to the requirements document will sometimes highlight areas where the requirements may not be clear but also gives the developer the ability to “test like a user” (well, in theory anyways).

Undocumented “Features”/Implied Requirements
No matter how complete the requirements document is there is always potential for miscommunication. I believe there are several features in an application that are just assumed. For example, when a feature is to “save the customer” it is unlikely that would be interrupted as saving that information only as long as the application is open (persisted in memory versus persisted to a file or a database). It would be assumed this information should be available the next time the application is loaded as well.

Other areas that I have seen implied requirements are:

  • Validation � It may not be in the requirements document but if a user types a letter into a number field it shouldn’t crash the application
  • Security � In a multi-user environment users shouldn’t be able to delete data that doesn’t belong to them (assuming user data is private in this scenario)
  • Application Interface Consistency � This often gets overlooked in larger applications until several screens look different because each developer implemented it in their own way.

These particular examples could be covered off by standards documents so requirement documents don’t become bloated.

It Isn’t Written in Stone
The worst thing that could happen from a good requirements document is it is used as a replacement for conversation. A good requirements document is only the starting point for creating working software which is what both developers and users prefer.

February 17, 2007

Question Everything

Filed under: Home,Work — mikesdump @ 5:18 pm

I hate standards, process, and architecture (referred to as process throughout) or just about anything else formal that says, “We should always do it this way”. I cringe every time I hear, “we need to define a process for that”.

I’m not saying defining a process is a bad thing. Documented processes can help raise overall quality and give a consistent approach as a company grows. What is bad is when people believe they can stop thinking for themselves because there is a process that addresses a concern. What is worse is if the process fails and people don’t take responsibility for the failure but blame the process (AKA “blaming the Methodology”).

Then there is the opposite side of the spectrum. People that disagree with a process may decide not to ruffle any feathers and quietly not follow the process. Too often, people feel a process is written in stone and impossible to change. The problem with this belief is the process isn’t challenged when it should be.

I believe standards whether they are your own, your teams or the companies need to be questioned on a regular basis. Is the process still valid? What is the risk of removing the process? Is there still a benefit to keeping the process?

My general rule, when in doubt, question everything.

January 29, 2007


Filed under: Home,Work — mikesdump @ 1:18 pm

I received an e-mail today from someone I have never met. This person lives in Ontario working at A & W, and from the sounds of it he is unhappy. He is unhappy with his wage, with the training he has received (to be a trainer) and his manager. This gentleman was looking for more insight to my experiences at A & W (he came across my post here). I responded to his e-mail but got me thinking about my current and past jobs.

When I was finishing collage all I cared about was getting a job and experience as a professional developer. The salary didn’t matter too much to me at the time because I figured over time that would come. As time went on the salary issue became a larger and larger until I decided I had to find something else to make more money (funny how things worked out. I ended up getting laid off and had no salary).

My next job I was hired at $5000/year more than my previous job. I was really excited about this opportunity. Within 3 months I was reclassified as an intermediate developer and received another increase in wage. But after two years without an increase the salary didn’t seem adequate and I started to look elsewhere.

In both of these jobs my salary not being where I wanted eventually got me thinking about leaving. When I think about it now salary was definitely a factor but not the only one. My first job sucked. I spent lots of time doing on-site and telephone support, installing third-party applications, and maintaining programs written in languages I didn’t want to work in (Visual Fox Pro and MS Access).

Near the end of the second job I was much more aware of the office politics and the environment was changing for the worse. There was much less talking and laughing at work and some people were vocal in their disapproval projects continuing that made no immediate revenue (I was working on a no money project). Many of these changes resulted because the company was in financial difficultly and could no longer pay the staff on time.

I would be lying if I said I have never thought about leaving my current job. We have had many talented developers leave over the last 18 months and I’m sure they are all making more money than I am. Money, yes, it is on my mind but it isn’t the only thing. There have been several issues eating away at me from office politics to business decisions that make no sense.

Something I read a while back on leaving a job can be found here but the key points are:

It is important to differentiate the need to move on from a false view that the grass is greener somewhere else.

Need to move on:

  • You do not feel like you are growing.
  • You do not see that this will change in the near future.
  • You do not feel that you work is challenging.
  • You have interests that cannot be explored with your current work.
  • You want to make a career change.

Grass is greener:

  • If you leave, you would seek the same job at a different company.
  • Your complaints and frustrations are pretty common.
  • You have felt the same way at other companies.
  • You are drawn to an idealistic picture of a different company. If your desire to move is more about the company than the work, I would urge caution.
  • You have been in your position less than two years.

When I read the “Need to move on” section my answers are:

  • Nope, I still have lots I can learn
  • I believe change is coming that will resolve some longstanding issues
  • There are challenges and some of them I like 🙂
  • From a development point of view there is a wide range of options at my current job
  • Not yet but I have been thinking about being an electrician 🙂

Overall I am still pretty positive about my current place of work. At every job I have ever had there has always been a certain level of crap that I have to put up with. If there is no crap you wouldn’t be paid to be there. As for money, odds are, as long as I’m working what I’m paid will never be enough. There is always a reason I “need” to make more. If you have a job and your only complaint is the money then it is probably a hell of a good place to work. If money isn’t the only complaint and you can’t change it, well that’s another story.

August 8, 2006

Key Interview Answers to Prep

Filed under: Work — mikesdump @ 2:21 pm

I received an email the other day from a local headhunter providing advice on how to prepare for you next interview. Their answer to a common question that caught my eye was this one:

5. What did you dislike about your last project or job?
You need to be cautious about these kinds of questions and make sure you do not end up making any negative comments. You need to turn this question into a positive one. It may be best to say that you really enjoyed many aspects of your past project, then focus on how this new project will give you the opportunity to contribute more in a particular area that is key to the position.

Umm, What!? Make sure you don’t end up making any negative comments? Doesn’t “dislike” imply they are looking for some negativity?
Let’s pretend your current position has you at your knees from “Analysis Paralysis”. If all you are after is getting the new job by all means lie through your teeth and tell them how much you love every aspect of your job. But, if you are trying to find something better and don’t want to move from one bad situation to another I would try one thing, the truth.
I don’t believe you have to slam you current/previous employer but be honest about what you like and what you don’t. If you hate the development methodology don’t say your current project manager is so non-agile that they can’t spell XP. Try, “I don’t see any opportunity to be involved in an agile project with my current employer. I have read about Extreme Programming and Scrum and I’m interested in being involved with a team like that. What type of development methodologies do you use here”?
Too much focus is put on “surviving” the interview that sometimes people loose focus that they should be trying to determine if it is a place they want to work.

August 4, 2005

What is Your Job Description?

Filed under: Work — mikesdump @ 1:06 pm

Think about that question for a minute… What is your job description?

Now I’m sure you have all kinds of duties that you do day in and day
out but when thinking about your job description where did you rank
customer service? Did it make your list? Based on my observations a lot
of people don’t even consider it.

Something that I’ve learnt in my relatively short working career is
that the number one responsibility of anyone involved in producing a
product or service is customer service. Any business that doesn’t
believe this must have no competition in their sector so they can get
away with lousy customer service. Any business that does strive to
provide the best possible customer service is not only limiting its own
growth but it will probably lead to its ultimate demise.

There are a couple of reasons that I feel so strongly about the
importance of customer service. The first one is related to experiences
at my previous job and the second is related to my very first job.
These experiences have had a great influence on the way that I work

My previous job was at a software company that I worked at for a total
of 3 1/2 years. The last 1 1/2 years of my employment I was not paid on
time. When I finally quit I was behind by 2 full months of pay (I did
eventually get paid). While the company was in financial difficultly
the staff received regular updates on when we could expect to be paid.
We heard on a regular basis that getting our paycheck relied on some
user acceptance testing being successful, or one of the development
teams delivering a bug fix, or a sales person closing a deal.

With the situation at hand it was obvious to see the importance for us
to work as quickly as possible but also to provide excellent quality
because if we didn’t the customer could reject it (if you were a
customer would you pay for substandard work?). People hungry for a
paycheck (hopefully not just hungry) would question everything that was
done. Do we really need to be working on that project? Is there any
other billable work that can be done first? Is there any other way that
I can help? Yes, the overall driving force for people was to get a
paycheck so they could survive but the writing on the wall was:
Customer service = paycheck. In most companies individuals don’t feel
these pressures (exception might be commission sales people). “It will
get done when it’s done”. Anyone with that mentality probably wouldn’t
survive running his or her own business.

My very first job (well that lasted more than a couple of months) was
working for A & W. I know, “fast food?” but there was an important
lesson here. A & W required every employee to memorize the company
mission statement within their first 3 months of work. With the average
employee age probably being around 16 I thought it was pretty stupid at
the time. Most people working there just wanted to put in their time
and take the shitty 5 bucks an hour. I really don’t remember what the
words of the mission statement were but the idea was to exceed customer
and each other’s expectations. It wasn’t enough to punch in the order
and toss the food to the customer. The mission was to exceed their
expectations. The part of the mission that stands out to me the most
was “and each other’s”. That meant that our co-workers and the managers
were our customers as well, I was the manager’s customer. I had a hard
time believing that the company really felt that way about me. I
thought that if I wanted any sort of advancement that I would have to
exceed their expectations but in what way would that treatment ever be

My work ethic earned me some brownie points and I was told I would be
made an assistant manager. The title was really meaningless to mean
because I already did the work but I wanted the pay that would go along
with it. Some time passed and I was told I could have the title but I
wouldn’t get the raise that went along with it because that store
couldn’t afford it (ya right). I was pissed! I worked my ass off for a
shitty wage, was promised an increase but I didn’t get it. So, I found
another job that paid what they promised me (wasn’t hard finding a job
for $5.50/hour).

When the district manager asked me why I was quitting I said, “not only
did you not exceed my expectations but you didn’t even meet them. You
don’t practice what you preach”. I thought that would be that and I
went on to the other job. I hated it and quit after a day (it was a car
wash). About 2 weeks later the district manager called me offering me a
job at another store for more than what she originally offered. I was
amazed. Looking at the situation “half empty” you could say that they
should have done that to begin with but that fact that they did it at
all I was truly impressed. Treating the people you work with like your
very best customer = an excellent working environment = people that
want to exceed.

Stating loudly and clearly that exceeding customer expectations is the
number one priority of an organization will pay off if people believe
the importance of it. The hard part is creating the work environment
where everyone is treated like the very best customer so they are
driven to want to exceed.

May 18, 2005

define: Team

Filed under: Work — mikesdump @ 10:32 am

google define: Team

A team comprises any group of people
or animals linked in a common purpose. A group in itself does not
necessarily constitute a team.

I work with an excellent team of developers. But when I include Sales I
would classify this as a group. As a development team we have been
working to try and put on paper our vision/mission but I believe we
already share a common purpose. Some goals that the development team
shares: desire to develop high quality software, continuous self/team
improvement, and strive to provide excellent customer service to name a

Sales on the other hand have very different goals in my opinion. Their
task, a very difficult one, is to continue to find new customers in
order to keep the business going. I have been in commission sales and I
know the pain that if you don’t sell you don’t get paid. Perhaps there
are quotas that need to be met in order to keep your job. Even if sales
aren’t on commission it is in every business plan to continue to grow
and that challenge normally falls to the sales team.

If the sales team sells just what you have I think the two groups can
co-exist. But when new functionality is constantly sold with delivery
dates given before the development team gets a chance to review the
requirements there is no team. I have never heard from any developer,
anywhere, how great the sales team was. How they set realistic customer
expectations right from the start. An us versus them mentality
unfortunately is far too common.

Now it can easily be argued that my goals/mission are misaligned with
sales or perhaps even the company. Some days, after a self-evaluation,
I would even agree with that. But if all that was ever asked of
developers is to crank out code that was just good enough for today,
with no concern for maintainability or how the rest of the system would
be impacted, developers that care would be become frustrated. They
wouldn’t be able to improve their skills and ultimately would end up
providing poor customer service because these types of solutions are
generally pretty fragile. For the developers this pain would be
temporary because they would move on. In the long run the company would

So what is the happy ending? I think the only way for sales and
developers to become a team is to have a better understanding of each
other and have a common vision and mission. The vision will provide the
dream. It says this is where we want to go together. The mission
defines how we get there. It should define what should and shouldn’t be
done by both sides. It isn’t enough to produce a document that gets
hung on the wall, it has to be lived everyday and become part of the
culture. Sounds pretty simple don’t you think 🙂

Next Page »

Blog at WordPress.com.