Sunday, December 29, 2013

Year-end compilation of sayings

You may or may or may not find these usefull in the new year.  (The are in no particular order.) 

  • The key to project management is "communicate, communicate, communicate". -- Dr Gary J. Evans. 
  • Everything happens for a reason and a purpose, and it serves you. -- Anthony Robbins
  • Lead follow or get out of the way. -- Thomas Paine 
  • All that is necessary  for the triumph of evil is for good men to do nothing. -- Edmund Burke  
  • The five reasons babies cry are: hungry, messy, tired, gas, sick. Don't forget any of them. -- Jeff Spiller
  • Entities should not be multiplied unnecessarily.-- William of Occham. 

Sunday, December 22, 2013

Small Project Risk

How many times have you heard (or told) stories about system that can't be upgraded because it only runs on [insert your outdated operating system version here]. Or, we can't do that worthwhile project because the [insert program/script/report name here] won't handle the capacity and we can't [spend the time or money to]  fix it. Frequently you find that,  in the scheme of things,  these are small programs, written years past with the best intentions. The long term issues were just unanticipated.

Any time you work on a small software project  its easy to identify short-term risks, for example:
  • Will the project get done on time? 
  • Will it work properly? 
  • Will the implementation go smoothly? 
Frequently, however, we ignore long-term risks like:
  • What if the underlying technology becomes outdated/unsupported before the project outlives is usefulness.
  • What it this is needed beyond is projected lifespan/capacity
  • What level of additional complexity will it add when we change/update systems
  • How will it limit our ability to react to changing conditions

We manage the short-term risks because they are typically known, and the project won't be a success if we don't. We ignore the long-term risks because it's a small project, its impact appears to insignificant and the expense of mitigating those risks does not seem to be worthwhile.

Unfortunately for some small projects, the impact of its failure grows over time, and the long-term risks become very significant.

On small projects try to ask yourself questions like this:
  • What will the significance of the this project be if its use grows  over time?
  • What will happen if we have to change program this frequently ?
  • What other systems depend of this program, what happens if their significance changes ?

Saturday, December 14, 2013

My Application for CEO of Microsoft

Dear Microsoft CEO Selection Committee,

I know that you are actively looking for a new CEO and I am quite sure that I am at the top of your list even though you haven't contacted me ... yet. In the spirit of letting you know what you will be getting, I would like to outline my plan for Microsoft's future. The theme of my plan is 'Breaking up is the only thing to do'.

In the last 30 + years Microsoft grown from from a tiny start-up into one of the largest technology powerhouses in the world. But, as with any company, there comes a point where if the company continues grow and diversify it will be crushed under  its own weight. Microsoft is at this point. The best move for the company and its shareholders is to break Microsoft into three companies:

1. WindowsOS, Inc. This company will open source the Windows desktop and server operating systems and Internet Explorer.  It will provide development, support, and maintenance in a model similar to RedHat or Ubuntu. Open sourcing Windows  has much better potential because the OS is fast becoming a commodity, and open source is an excellent and cost effective model for a commodity software business

2. XBox. Inc. This company will comprise of Windows devices including phones, game consoles, and tablets. It will also own the Windows 8 mobile OS. This company will focus on consumers with known name and flagship product.

3. Microsoft, Inc. This company will retain the high value applications that power business. Branded with the with the familiar and enterprise friendly Microsoft name, it will include SQLServer, Visual Studio and development tools, Exchange, and Dynamics. It will focuses on the Enterprise market. These tools will be ported to Linux over time to increase market share.

As for Bing-- I will sell it to whomever wants it (though preferably not Google since competition is a good thing). Microsoft does not need to compete with Google on is battlefield of choice.

I know that this is drastic move and there are details to be hashed out. In the long run, however, Microsoft's 'babies' can focus on their own businesses rather than trying to balance out competing demands from other units. My contact information is on this blog, and I expect to hear from you soon.


Jeff Spiller

Saturday, November 30, 2013


At thanksgiving you always find out what the rest of the family is doing. This year I learned that one of my cousins was in the early stages of of a technology start-up. The fact that she is leading a start-up isn't really as surprise, but how she's doing it is a bit unusual for your average start-up traditionalist. She has a group of developers creating her application for free. Why are they doing this? First, because they think is 'cool' and second because they trust her. There are no contracts or lawyers. They this think this is a great idea, and that my cousin will take care of them if it works out. What a great way to manage lead a team.

Tuesday, November 26, 2013

The future of desktops

Everyone is talking about the future of desktops. If you read the headlines you would assume that 5 years from now everyone will be using a tablet, and we will never see a desktop again. I think that assumption is a bit silly.  We will still have to go to work, sit at desks, and type things into  computers, Its a heck of a lot easier to do that with a keyboard, monitor, and mouse rather than a touch screen. The real question is what will the desktop itself (the hardware) be doing. Most likely it will be a platform for delivering cloud based technology. Your main system (which may be MS Windows) will be on a virtual machine, your web/cloud bases apps will be in a browser. You desktop PC will be  primarily a portal. Since its not doing much, you won't need tons of hardware, nor will you want to spend a fortune on an operating system. This is a great opportunity for Linux. For those of you who enjoy irony, imagine an office full of Linux desktops running VDI clients with MS Windows as the guest O/S.

Saturday, November 16, 2013

Tools are Tools

We are constantly bombarded with new tools that offer the promise of better productivity, quality, profit...,etc; there's lean, agile, project management, TQM and many more.  While all of these tools can provide great benefits, frequently they are confused as the end rather than the means. No matter what tool(s) you use, they are only as useful as the people who use them and the plans they support. Great tools don't fix bad management, poor planning, or lack of vision (but they sure look good). Before you invest in a tool make sure you have your fundamentals (people and plans)  in place.  Remember, quality buildings were created before the invention of power tools, and great businesses were founded before books on  'modern management techniques' were published.

Saturday, November 9, 2013

My pet-peeve list of productivity sucking technology for developers.

  1. Eclipse - Why isn't this as easy as Netbeans ?.
  2. Windows Version Upgrades  - You had to move user directories and admin tools. ?
  3. Windows Server 2008. - How can you release a 'server' operating system that, for security reasons, can't run scheduled tasks out of the box ?
  4. Gnome3. - Really, a task bar wasn't good enough?
  5. Software without installs for major OSs. - I have to build my own stuff, why do I have to build yours ?

Friday, November 8, 2013

The Joy of a Big Grails Version Upgrade

I had the joy of upgrading from Grails 1.3.7 to 2.3.2 this morning (new computer). After three hours of upgrade fun I finally got everything to work.  For those of you who are making a big jump with grails here's what I had to do: 

1. Upgrade grails.
2. Attempt a compile.
3. Uncomment all of the maven update locations in buildconfig.groovy
3. Uninstall each plugin that failed.  Note, you don't use a script to uninstall the plugin, you need to remove the plugin entry from the file in the in your application's root directory.
4. Install the new plugin. Again no script, you create an entry in the buildconfig.groovy file. 
(By the way if you use the script to try to install/remove a plugin,  it does give you instructions about the new way to get them to work.)
5. Guess what, scaffolding is now a plugin, so you'll need to add it if you want any scaffolded controllers to work.

(Its good practice to run the clean script between each step to save you some greif.)

The good news is my other application only took 3 minutes to upgrade once I knew what I was doing.

I'm sorry that I don't have any examples of the changes that I made. I'm not near my work computer right now. I'll try and add some later.

Wednesday, November 6, 2013

Personal Rule-of-Thumb.

I frequently have to deal with requests from users.  Over time I've come up with a four part method of deciding if I should classify a request as  a 'project' and put it through the project management process, or  a 'task' that I can do without too much ceremony. After some creative brainstorming I even came up with an acronym. It's not a project if its SLIM

Short Time. It will take less than two hours.
Limited Parties. Not more than 2 other people involved.
No Process Impact. It won't change how an existing process  works (no training or user doc , etc)
Mostly Self Contained. It won't require a lot of interaction with other program and data flows, data in or out does not need to be changed.

What types of 'personal' rules-of-thumb do you have to organize your time ?

Sunday, November 3, 2013

5 Reasons Why The Ops Team Won't Load Updates

5. You changed the interface
4. You added a feature
3. You didn't test everything
2. The last time we loaded an update you didn't test anything
1. Loading an update will require missing the football game this weekend

See also: 5 Reasons Why The Dev Team Creates Updates

5 Reasons Why The Dev Team Creates Updates

5. You said there was a problem with the user interface
4. You said we needed a new feature
3. Something was broken and you wanted it fixed
2. You said you had to have it 'as soon as possible' .. or else
1. Writing code means missing a trip to the ballet

See also: 5 Reasons Why The Ops Team Won't Load Updates

Saturday, September 7, 2013

What type of business problems of you have?

This is a shameless plug for ideas to blog about. Add a comment and let me know what type of issues you have.  (in business and IT please)


Problem solved: Content ideas. 

Sunday, September 1, 2013

Making a Leader

Imagine if you took your average homeowner (who is not a carpenter or in the building trades), lets call her Barbara, sent her to furniture-making boot camp. At 'boot-camp' she learned how to use all the tools that one might use to make furniture.  After graduation you  ask Barbara to build you a chest of drawers. Keep in mind that Barbara probably has used, bought, and may have even assembled a [Scandinavian style] chest of drawers, but has never build any furniture from scratch before. At the same time Barbara is making her chest of drawers, you ask a master furniture craftsman to also make a chest of drawers. Which one of these chests of drawers do you think will you be more likely to sell at a garage sale (if you are lucky) vs. a furniture store?

(I'm assuming that you picked Barbara's  for the 'lucky to sell at a garage sale' award, and the Craftsman's for the the store, since that's where I was trying to go with this story.) 

It's obvious that in addition to knowing how to use tools, and knowing what a good outcome looks like, you have to actually have experience with the process of building furniture to get a quality outcome. What do you think the outcome would have been if the Craftsman would have worked with Barbara to create the furniture. I suspect the outcome would have been of a much higher quality. 

How many people have you seen promoted to a management position, sent to a week-long seminar on management and left to fend for themselves for some 'probationary' period of time without any other guidance. They have the tools, they know what the outcome should look like, but they still don't perform to expectations. What if they had a mentor to guide them, wouldn't the outcome be better? 

Problem Solved:  Developing Leaders

Saturday, June 29, 2013

How much could you make balloon twisting

Every once in a while, I'll see someone dong something and wonder "how much do you think this person makes dong this?" It's  more of a mental exercise rather than a practical one, since I really don't know the business in question. 

Last week I went out to eat with my family at a local restaurant and there was a person walking making  balloon animals, with a button that said "I twist for tips".  How much could you make?

My assumptions (that may be wrong):
Average cost per balloon: $.06
Upfront balloon Investment: 500 balloons x .06 = $30.00
Balloon pump: $10.00
Button: $5.00
Pouch for supplies: $10.00
Average number of balloons per animal: 2
Average tip per animal: $1.00

Startup capital needed: $ 55.00 ( balloons,pump,pouch,button)
Average cost per baloon animal: $0.12 (two balloons)
Average revenue per baloon animal: $0.88

The profit
So if you worked for 4 hours, and made 8 balloons an hour, you  would make 32 balloons.
That would net you 28.16 in profit per day. ($0.88 x 32), or $6.52 per hour. 
If you did this Friday and Saturday 48 weeks a year you could make $2,511.36 per year (2 days x 48 weeks x $26.11 per day)

Good news: you break even on your third day. 
Bad news: you could make more per hour working at a fast food restaurant. 
It would be a much better deal if the restaurant paid you too, or you passed out cards promoting your other "balloon animals for parties" business. 

Problem solved: Making money twisting balloons.

Disclaimer: This post should not be used to make a decision about a balloon twisting business. 

Monday, June 17, 2013

Starting the healing process

Problems, like wounds can fester. Frequently everyone involved with an issue quickly takes a 'defensive' posture, the wound abbesses, and then explodes. (Anyone with a cat that gets in fights has seen this). After the explosion, frequently, someone new comes in to clean up the mess. Early in my career, I had to take on the clean-up role. I found that the best way to sooth feelings and diffuse tension  was with this line: "I understand you are upset with this situation, but I can't fix what happened, all I can do is change things going forward." One you say this you better follow through, because it is just a start. 

Problem Solved: A new beginning. 

Sunday, May 12, 2013

Selling Magic

Any sufficiently advanced technology is indistinguishable from magic. -- Arthur C. Clarke
There is frequently a tension that builds between the Information Technology (IT) Department and the rest of the business (ROB) as a company grows. Today, in most businesses,  IT is essential to the businesses without being the business. And while there are other critical 'supporting' business functions, like HR and accounting, the ROB can understand these functions at some basic level, IT usually is harder to understand. For example, trying to explain Virtual Desktop Infrastructure (VDI) to a non-IT person is a challenge  because the outcome for that user is essentially the same thing they have now. And worse yet, if it works, the user will barely notice it.   This stuff looks like magic to ROB. We could just as well tell them them we need half-a-million dollars for magic pixie dust that will keep the desktops running, because that's what it sounds like to them anyway.* So, why is knowing this about the ROB important anyway? Because if IT wants to be able to serve the ROB in the manner it should, IT needs to learn how to communicate its needs properly to the ROB.

There are only three benefits the ROB cares about, making money, saving money, and mitigating risk, and in most cases they are prioritized in that order. Any proposal should be based on those items. Don't waste time trying explain the technology in detail, you can always do that off-line. Each of these benefits are concrete, and can be expressed with numbers. Make sure you back can back the numbers up with credible facts and sources. Once you have your numbers you can show the ROI for the proposal. Keep in mind however, that sometimes, the ROB can get a better ROI from something else, and they will choose to spend the money on that project.

*I am not implying in any way that the ROB is stupid, they just have not spent years and years immersed in IT. I think that what my auto mechanic does my as well be magic because I have not invested the time necessary to understand it. 

Problem Solved: Selling Technology

Sunday, April 7, 2013


." is the enemy of the good." -- La B├ęgueule by Voltaire

You will never achieve perfection so pick a point where it's good enough and act.  If you don't, you will never get anything accomplished.  Perfection resembles its cousin procrastination.

Problem Solved: Perfection

Sunday, March 17, 2013


To Improve a process you must measure it , to measure it  you must repeat it, to repeat it you must have procedures. -- Unknown

To break it down:

  1. You cannot know if  you are improving unless you have some quantifiable way of measuring change.
  2. You cannot measure your change unless you can repeat the process to see the effect of the change.
  3. You cannot repeat a process if you don't have procedures to ensure that you do it the same way each time. Without procedures there is no way to know what changed, and what effect it had on the process.

If you know where this quote comes from please comment, I don't believe that I have the insight to come up with it on my own.

Problem Solved: Process Improvement

Saturday, March 9, 2013

What's My Line

My Blog has a tagline "Identify,Improvise,Adapt,Overcome,Enhance". In addition to the  "Improvise, Adapt, Overcome" Marine tie-in (Marines like all of our armed forces are cool), I constructed it because its a good framework for  problem solving.

Identify. Make sure you know what problem you are solving. If your house is dark, Its best to know if the power is out, or the light switch is off, or a light bulb is blown, before you work on a solution. Make sure you do some troubleshooting to ensure that you are working on the right issue.

Improvise. Take stock of your available resources. Frequently some of your resources will be intellectual (people who know stuff). In the dark house example, it might mean looking for batteries and flashlights, or calling your spouse to find out where the candles and matches are.

Adapt. Make a plan to use your resources to solve your problem. You can use the flashlight to read. You can light the kitchen with candlelight.

Overcome. Implement the plan. Make dinner by candle light, Read the mail with the light from a flashlight.

Enhance. Review the situation. What did you learn? What you could do better? For instance in my example, you may want to have an agreed upon location with your spouse for candles and matches. Possibly you need to set a reminder to check battery inventory monthly. You may want to buy a generator if the power goes out often.

Problem Solved: Solving Problems

Related: Fixing my fence, the ITIL way

Saturday, March 2, 2013

Top 5 Reasons why I would have done what Ms. Mayer did at Yahoo!

I don't have any particular interest in Yahoo! other then having an account in the past, nor do I know or have any connection the Ms. Mayer. I, however, feel the desire to provide some context to her decision to cancel the company's remote working program since she is in my dream job (saving a failing business), and this type of tempest-in-a-teapot creates great blog fodder.

Top 5 Reasons why I would have done what Ms. Mayer did at Yahoo!

5. Remote workers were not particularly productive.
4. Management was incapable of properly supervising remote workers.
3. Processes, procedures, and infrastructure were not in place to properly manage remote workers.
2. Company culture was complacent and resistant to change and needed to be shaken up.
1. I, as the CEO, needed to flex my muscles, so to speak, to 'motivate' employees to change.

Also, keep in mind that Yahoo! is in a somewhat dire situation and drastic actions may be necessary to fix it.

Problem Solved: Fixing a failing business.

Wednesday, January 30, 2013

When to change

I  recently wrote a post on why an organization cannot rely solely on continuous improvement to ensure growth. While the article was long on theory it was short on practical advice. In order to rectify that oversight, I've made a list of some situations that might indicate its time for a radical change rather than business as usual.

It may be time to shake it up when: 

  1. Technology Changes.. It could be the technology you are using, selling, or your customers are using
  2. Market changes. Massive reduction or massive growth
  3. Resource Issues. Not enough space, not enough employees
  4. Macroeconomic Issues. Recession or  expansion of the economy
  5. Regulatory Issues. Something is illegal that used to be legal or vice-versa
  6. Competitive Issues. Lots of new competitors
  7. Stagnant Growth. You are not growing very much or at all
  8. Comfort. Everyone just seems a bit too comfortable and complacent

Hope this gives you food for thought.

Sunday, January 27, 2013

When Continuous Improvement Doesn't

Business today is all about some type of  Continuous Improvement (CI) process. We hear about it all the time -- Six Sigma, Lean, Agile,ITIL. Primarily based on the Demming Cycle, CI processes have been shown to significantly improve quality, and can be credited with many significant business success. (Toyota  before 1999 is the poster child for CI.)  The problem, however, with CI is the 'I' -- improvement.

When you improve something you you take something that exists, and you make it better, but you have to respect the law of diminishing returns.  For example, if you have 5% marketshare, it's possible to double your marketshare over some amount of time, but if you have 80% marketshare its impossible to double it. (While I used marketshare as an example here, there are physical limits to all processes that apply in the same way.)  In other words, at some point you won't be able to significantly improve a process/business/product, and in order to grow you are going to have to change. 

Implementing a CI process is a change, but having one does not absolve you having to change again. Frequently I see business with CI processes that begin to believe their own propaganda about quality, and improvement, and think that the CI is the change. (Toyota of the 2000s is an example of this). Small companies suffer from this as well, typically as a result of growth. The old systems, organization structures, and process that worked once, no matter how they are improved, cannot meet the new realities. But, in order to preserve 'the culture of CI' that is currently in place nothing is  really changed.

Change is no fun, but if you don't want to end up on the decline end of the business life cycle you have to do it. But remember change, that will extend you growth curve, is big, risky, destructive, and somewhat painful. While I don't suggest you do changes like this regularly, you do have to monitor your business, and when you see the signs of diminishing returns you need to act.