Thought I’d share this recent event.

A non-technical colleague at work asked me to see if I could open up what he thought was an Excel spreadsheet, sent by another person to him. He wanted to rule out that it wasn’t an Excel version issue (I’m running 2010, him 2003).

Like him, I was getting the same error, “file format is not valid.”

However the subject of the email, as forwarded from the original sender, implied that it was XML data. So my next step was to open it up in a text editor to see what the content looked like.

Clearly not an XML file, but some sort of binary file. But did notice the small nuggets of plain text located in the file, and then did a Google on those bits and first try gave me this:

As a next step I renamed the extension from .xlsx to .xps, and sure enough – that worked!

I’m so surprised that I got that lucky on the first try I had to share the experience.

Often organizations can find themselves under a mountain of requests and they can’t see the forest from the trees. It’s overwhelming and management may not know where to start – so they don’t, and what ends up happening is the organization becomes short sighted. Meaning that priorities are a reaction to today’s biggest issue, efforts are directionless, and most requests are escalated up the management change.

[box]Vision[/box]

The source of the problem stems from lack of vision, and the corporate objectives that come as a result.

To get a grip on priorities you have to start with having a vision – even if it’s just a simple one line statement of where you’re aiming at; it’s the step to narrowing a blurry view into a focused one by getting everyone pointed in the same direction.

In essence all a vision is, is a statement of where you aim to be. Without one, there is no direction – you can move fast, but moving fast in a circle results in moving no where.

[box] Corporate Objectives[/box]

From that vision, define your corporate objectives or goals. These are specific, measurable, achievable, realistic, and time bound (aka S.M.A.R.T goals).

For example:

• Increase delivery time of widgets by 10% over the next 12 months.
• Decrease customer complaints by 5% over the next quarter.
• Decrease network outages to less than 5 minutes by 06/01/13.

[box]Nested Objectives[/box]

As a corporation you only need 2 to 5 of these; each organization underneath you will have nested objectives that support your top level goals. And now that these have been defined, you have the various projects that support each of these objectives.

[box]Alignment of Projects[/box]

So go back to your endless laundry list of requests, priorities, enhancements, and projects and first determine which ones are supportive of the goals in your organization. If they do not support the goals, then you have to simply put them aside – even if they’re good ideas.

[box]Executive Sponsorship[/box]

What’s left requires evaluating if projects have an executive sponsor. If a project is unsupported, you’re taking a huge risk by investing any effort in such a thing. There may be ROI, and it may support the goals, but without executive sponsorship the chances that the project will be successful is highly doubtful. This is because the project will then hinge it’s success purely on the ability for all the teams involved to function by consensus; and of course all serious projects come to serious forks in the road where differences in opinion will deadlock the project – an executive sponsor can make those tough decisions.

Another reason why executive sponsorship is needed is because if each team involved doesn’t have their portions of the project as deliverables as part of their performance plan, there’s no incentive for them to put in the effort. In fact, putting in any time, takes away from projects they are on the hook for.

Lastly, if an executive finds out you spent a large amount of money and it didn’t pay off, now you’re in deep water with no one to support you.

[box] ROI[/box]

Ok, now you have a list of projects that are aligned to the goals of the corporation, and have the executive sponsor to back it. You still will have a list of projects that require more resources than you have, the next step is to evaluate the potential Return On Investment (ROI).

The ROI comes in the simple and tangible form of quantitative, and the difficult to measure qualitative. Projects that have more quantitative ROI are the ones you want to go after, as they’re easier to measure the actual results (increased revenues, cost savings, etc…). Versus the qualitative ROI which is almost impossible to measure, and even more difficult to actualize.

Of the quantitative ones you want to evaluate the actual potential ROI, how easy it is to actualize that ROI, and how you’re going to actualize the ROI (projects that don’t require anything to actualize are the best, e.g. switching to a lower cost vendor).

Here are some things to think about. If you reduce the time it takes to do something, what’s the return? From a financial and quantitative perspective the answer is none.

The return is when you see the impact to the bottom line – now saving time definitely has qualitative benefits, but the point here is as high as an ROI is, you need to assess how capable your management organization is at being able to actualize the ROI.

E.g. does it entail reducing overhead, reducing headcount, restructuring the organization, etc… Say that project can save $50M, but costs $100M – your ROI 50% in one year. Compare that to a project that costs $100, and saves you $100/yr, this has a 100% ROI.

So keep a relative perspective in mind as well; smaller projects may not have the huge total numbers of bigger projects, but their ROI is much easier to actualize and therefore lower risk.

The bottom line is you need to rank projects by ROI- giving extra points to projects with more quantitative than qualitative, giving extra points to the ROI ratio, and extra points to ease of ROI actualization.

You can only calculate ROI if you have the (I)nvestment portion, so you pick off the top x projects until all your resources are booked for whatever time frame you’re working with.

[box] Conclusion[/box]

Using this formula will help you get a grip on priorities and get your organization executing on a path that will allow the organization to achieve its goals.

The New Yorker published a lengthy editorial on how natural human behavior affects the scientific community when it comes to studies, in that selective reporting and significance chasing leads to ‘publishing bias’.

“the act of measurement is going to be vulnerable to all sorts of perception biases. That’s just the way human beings work.”

“researchers engage in what he calls “significance chasing,” or finding ways to interpret the data so that it passes the statistical test of significance – the ninety-five-per-cent boundary invented by Ronald Fisher. The scientists are so eager to pass this magical test that they start playing around with the numbers, trying to find anything that seems worthy,”

“…the decline effect is largely a product of publication bias, or the tendency of scientists and scientific journals to prefer positive data over null results, which is what happens when no effect is found. The bias was first identified by the statistician Theodore Sterling, in 1959, after he noticed that ninety-seven per cent of all published psychological studies with statistically significant data found the effect they were looking for.”

“The decline effect is troubling because it reminds us how difficult it is to prove anything. We like to pretend that our experiments define the truth for us. But that’s often not the case. Just because an idea is true doesn’t mean it can be proved. And just because an idea can be proved doesn’t mean it’s true. When the experiments are done, we still have to choose what to believe…”

Although the context is regarding the scientific community, I was thinking how there are direct parallels to the business and B.I community as well. perhaps we’re too focused on the pursuit of truth, when the ‘reality’ is that there no truth, only perception & interpretation.

So instead of using data to prove things, we need to look at data to be more of a guide. For example monitoring trends, inflection points, velocity of change over specific numbers. Not that specific numbers are unimportant (e.g. shareholders will continued to demand exact profitability statements), but in terms of managing a business not to exhaust enormous efforts on proving perceptions/suspicions/hypotheses but to define data driven decision supporting guides.

At many companies decisions and prioritization tends to be done by committees, in fact Agile itself tends to be very committee driven (the team estimates together, the team determines how things will get done, etc…).

But the Product Owner (or Product Manager in traditional terms) is the key person who’s accountable for the results. They prioritize the projects and features, define desired outcomes, ensure profitability, and accept/reject results.

In the real world many people may have a stake in projects as they are either sponsoring the project, supporting the project, or are affected by the project. So as a Product Owner you will have to interface with stakeholders and sponsors to get their feedback, issues, goals, etc…

Likewise, a Project Manager/ScrumMaster might encounter similar situations where they are trying to garner consensus and agreement.

The problem however is that large committees rarely are capable of making decisions.

[box] Once you’ve got 7 people in a decision-making group, each additional member reduces decision effectiveness by 10%, according to Marcia W. Blenko, Michael C. Mankins, and Paul Rogers, authors of Decide & Deliver: 5 Steps to Breakthrough Performance in Your Organization. Thus, a group of 17 or more rarely makes any decisions.[/box]

Tips:

• Hold a series of smaller sessions (e.g. instead of one 10 person meeting, have two separate 5 person meetings).
• Pre-meet in advance with individuals to gather their feedback, stance, concerns, requirements to that you can factor that in and further prepare for the main meeting.
• Instead of starting with a blank slate and trying to work with the committee to collaborative decide/plan/prioritize/etc… gather initial data and create a good starting point – e.g. a draft plan, and then let people argue/discuss over it.
• Always make sure your management supports where you want to go so that they back you up behind the scenes.

I’ve been working on this small application as I continue to tinker around with Grails, and set the source code management up through GitHub so that I can synchronize across machines. My Mac laptop has 2.1.0RC2 while my PC had 2.0.4 where I planned to upgrade to 2.1.0RC2 as well.

When I thought I was good to go I began running into some really strange errors:

I then attempted to do a “grails clean”, and experiment with creating a new app and copy in the source to see if that would make a difference, but continued to encounter the issue.

However I did notice in the output that it was referencing a c:\users\{user}\.grails\{version} directory and attempted to nuke the version folder, and still had the same issue.

However, deleting the entire .grails directory fixed the issue!

Conclusion

There’s obviously caching going on here, and I’m guessing the auto-wizardry that figures out plugin dependencies got out of sync. So deleting that directory causes Grails to download fresh all the components that it needs to build the app.

Error Signature

Error executing bootstraps: Error creating bean with name ‘transactionManagerPostProcessor’: Initialization of bean failed; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name ‘transactionManager’: Cannot resolve reference to bean ‘sessionFactory’ while setting bean property  ‘sessionFactory’;

From time to time we’ve has this ColdFusion error occur over a period of years regarding the setup of mail server parameters:

Message: An exception occurred when setting up mail server parameters. Detail : This exception was caused by: javax.mail.MessagingException:
Connect failed; nested exception is: java.net.SocketTimeoutException: Read timed out.

Once in this state, ColdFusion would no longer send emails anymore and the only solution was to restart CF. There are a number of discussions in the blogosphere and StackOverflow which we did look into and implemented various scripts to re-queue the emails, but it was annoying that we couldn’t determine the cause.

Recently it started up again, and what’s odd is we have 7 identical web servers behind a load balancer (VMs that were all coped off the same image), and only one of them was experiencing the issue (Windows 2003 Server, CF8 32bit).

Well we finally figured it out – it was McAfee anti-virus. Once we added an exception to not monitor the ColdFusion directory, the problems went away.

Hope that helps if anyone encounters this.

Recently on LinkedIn there were two separate threads in ColdFusion related forums regarding the topic of the challenge of finding ColdFusion developers as an employer, and finding jobs as a ColdFusion developer.

The discussion covered a variety of perspectives from telecommuting, the ecosystem, economic, tips on attracting developers, tips to finding jobs, etc…

Below is is an adaptation of my posts…

Telecommuting

I’m the Sr. Manager of a collection of technical teams (DBAs, Developers, and B.I), and we have had a few people work predominantly from home.

Of course there are a number of advantages from the employees perspective in that they get to recuperate time from commuting, expense of commuting, etc… I would say that the biggest advantage is the ability to focus. An office environment, particularly if you’re a key person on the team, can be a non-stop barrage of distraction. And if you are key person, the company benefits the most when you’re focused.

The flip-side

There are of course drawbacks.

We’ve seen that there is an isolation effect. Tools like Skype, WebEx, and TeamViewer are great tools, but nothing is like the experience of a face to face. Studies have shown that telecommuters do not advance as fast as their peers who work in the office. And let’s face it, we’re human beings and have evolved to interact with each other in person (give it another 50yrs and we’ll all be plugging into something like the Matrix and conduct face to faces in digital form).

We also find that the team chemistry and bonding evolves significantly slower among a group of telecommuters. Those side conversations, going out to lunch, sharing challenges while grabbing a coffee… those occurrences are far less with telecommuters.

Growing Jr staff

Another challenge is that Jr staff rely on the Sr staff. You can make progress with screen sharing and conference calls, but it is no way as smooth as quickly walking over to a whiteboard and coaching a Jr member. So if the Sr Developers are telecommuting, your cost to get a Jr ramped up and productive is considerable to the point that a manager would be evaluate if it’s even worth it.

On an individual level, can a person do X work in Y time, regardless if they’re in the office or not, sure.

But on a team building perspective, the chemistry, unity, and bonding to achieve cohesiveness is extremely important. And telecommuting poses some serious hurdles.

One alternate solution is a hybrid approach. We found that worked well with Sr. staff working 2 or 3 days at home, which allows them to focus. And the days that they’re in the office you get the team building, the coaching of the Jr staff, the face to face interaction, etc…

Some studies suggest there is an ROI with telecommuting. The ROI tends to be on an individual level. From a management perspective, you’re looking for the overall output of the team which is more than simply the sum of all individual output.

Company cultures are unique

Each company is unique. And good management recognizes their organization’s strengths, weaknesses, abilities, shortcomings, etc… So although studies and ROI case studies are useful data points, you do have to factor in the unique reality of your exact company.

Not impossible, just recognize the challenges

I’m not saying it’s impossible to achieve success with telecommuting (clearly, companies have), but it’s a significant challenge that management will bake into their staffing & organizational strategies because it may very well be that the company culture isn’t compatible with telecommuting.

Or likewise, if there is no team then there is no issue. So for very specialized skillsets, solo acts, multi-location organizations… it may be a no brainer in those cases.

Supply is limited

The supply is constrained on both sides, and are cause and effect of each other. Hard to find expertise will cause company strategy to change which expertise is needed. Fewer opportunities will cause the talent to move on to other technologies.

Thus, both companies and individuals need to be prepared to at least go national when recruiting/job hunting.

Tip for developers

• As developers, I’d avoid branding yourself as a developer of a specific technology. Go for versatility, technologies will come and go. E.g. don’t be a “ColdFusion Developer”, be a “Web Developer” who has expertise in various technologies.
• Developers, you need be involved in the community, building up your professional network, finding opportunities to network with future potential employers (e.g. touch base with guys who have influence over hiring decisions, send your resume in just so that they have it on file).
• If you’re one of those guys that picked up CF to fulfill a need, but don’t have a formal software engineering background, and feel you don’t have that strong understanding of programming fundamentals – build an application using an MVC framework (FW/1, ColdBox, etc…). It’s one of the easiest ways to take your skills to the next level. Reading books gets you good theory, but real learning comes from real world experience. This will give you an edge interviewing wise for the rare CF job that does come up.
• An even better step is to build a real world application using a language you don’t know using its most popular framework. Learning another language will actually boost your CF abilities as you’ll realize you can apply concepts from that other language to CF.
• Some  hot up and coming languages right now include Groovy/Grails, Clojure, and Scala.
• What to build? Volunteer to build something for a non-profit. Look at the company you work for and look at what is being done manually or what is a cumbersome process, and build a tool to solve for that problem. It needs to be real.

Tips for employers

• As employers, we need to be looking for strong developers in general. At Amcom Technology, we’ve found people who have a strong understanding of programming fundamentals and software design, strong problem solving abilities, and are quick learners are the key.
• The recruiting needs to begin long before a position even exists by forming relationships with people. And that needs to happen on both sides of the equation.
• Employers need to be forming relationships with the community, so that if an opportunity opens up you have relationships already formed with folks who potentially are fits for the position and it’s not a cold call (err email).

Lastly

The most important tip I can give, is send me your resume, or feel free to at least touch base. Ok, that is shameless. 🙂 But we have opportunities that come up from time to time, and I’d like to get to know you! tariq [at] amcomtech . net.

In Alessandro Di Fiore’s HBR article, “How to Get Past Your Customers’ lies“, he writes about the importance of doing your own market exploration instead of using market research analysts. Or in his own words:

These people have to be smart about business, strategy, and people because they’ve got to be able to spot the really significant behaviors and issues. And the best people to do that are going to be the folks in the top management team… who have the strategic understanding needed to recognize the opportunity and the authority to act quickly on it…

…can’t rely on market researchers and consultants to find the strategic insight for you. Real market research should be a core part of any top executive’s job and they should be going out doing observations and explorative probes of customers…

Steve Jobs has also been quoted as saying that Apple does not conduct market research. Specifically it came from a Fortune article in which he says:

“We do no market research. We don’t hire consultants. The only consultants I’ve ever hired in my 10 years is one firm to analyze Gateway’s retail strategy so I would not make some of the same mistakes they made [when launching Apple’s retail stores]. But we never hire consultants, per se. We just want to make great products.”

However when it comes to market research, it’s also about recognizing your organizations strengths and abilities, and leveraging what you’re good at.

Apple creates markets

For example Apple is strong at creating markets that don’t yet exist, which is often extremely risky and capital intensive, but has a huge pay off if successful. It automatically positions you as a dominating leader in that space and leaves everyone else trying to catch up and copy.

Samsung is the opposite

Try naming one innovative product from Samsung. Not to say they’re not innovators, they’re clearly not known for it.

However they’re the second largest conglomerate by revenue. They wait for others to prove a market exists, and use their strength in being able to copy & refine the idea to produce a high quality product at a low price point causing their competitors to take huge losses when trying to compete with them . Sony-Ericsson took a $317M loss last quarter, Motorola Mobility lost $80M, HTC’s sales have dropped by 41% since Q3 2011. Yet, Samsung’s mobile division sales growth was 300% last year, and aiming to double smartphone sales this year. Yet… they all sell basically the same thing.

Market research is perspective

Market research isn’t truth, it’s just perspective, a piece of information that you can use if you decide to. In Apple’s case, the market research wouldn’t be of much value to them as there’s no market to research – they make markets.

But for Samsung, because of their specific strengths, it’d give them some perspective on what price would people be willing to pay for a device that was similar to the iPhone but didn’t limit them to a particular carrier.

So I agree with Alessandro, in that you have to put on your customers’ shoes and see from your own eyes the opportunities that present themselves. But at the same time I wouldn’t completely discount the perspective that market research can bring, you just need to be cognizant to not let market research potentially blind you from opportunities.

Michael Wolfe on Quora posted an amazing analogy explaining why software development estimates are routinely way off, which results in developers padding their estimates to factor in the fudge of such inaccuracies.

Another thesis I’ve been pondering over lately are the terms “Software Engineering” and “Computer Science”, which imply that software development is purely scientific and engineering in nature. Most colleges run those programs out of their science or engineering departments, and the business surrounding technology (budgets, management, and processes) is premised on the assumption that coding is engineering in that it’s scientific, mathematical, calculate-able, and algorithmic.

All of that is a component for sure – but the process itself, the act of coding is much closer to art. You start off with an idea of what you need to do and how you’re going to do it, you start roughly putting it together, you realize later how things will really need to be put together so you make alterations/refactor, you get feedback from QA testers/analysts/focus groups, and continually refine until you get the final product.

So unless you’re solving the exact same problem every time, what exactly are we basing the effort on? If a carpet guy knows he can carpet a 2 bedroom house in a day, he can be very close with an estimate on a 4 bedroom house. And overtime, the variation of houses is fairly limited.

However, every software project is a new problem; why would the business ask to solve the same problem twice? So we’re estimating based off of as-similar projects done in the past, but unless it is purely a CRUD with zero rules, it’s unique.

Of course an estimate will always be an estimate. But plans & dates get created, promises are made around those estimates, and the estimates become commitments. Which then causes developers to factor in some fudge knowing that the estimate will become a commitment.

Would it help if we get rid of the word estimate and label that value for what it really is, the guess? Imagine updating all your change tracking, ticketing systems, and project management tools to replace the “Estimate” field with the term “Guess”? It would help manage some expectations as to what that number really represents.

The flip side

The problem on the flip side is that businesses are run by plans. They’re not designed to function off of guesses. For example Apple has to gets the contracts signed and dates sealed for the Apple WWDC, payments have to be made to Moscone, Moscone has to prep the building, Apple has to build their booths, sign up all the exhibitors, attendees, etc… so whatever software is planned to be presented has to be ready to roll by then.

It’s a fascinating challenge, and here are some thoughts.

1. Break down the problem into a collection of micro-small problems.
• Smaller problems are easier to size, internalize, and visualize. Many Agile based processes employ this in the form of small as possible user stories.
2. Get formulaic about it.
• If a team consistently applies a 2X b.s. factor, and is 80% accurate – you then have variables to build a formula & pattern around it where you project a target date -/+ x% based on the accuracy, and then build in risk mitigation strategies to make sure you’re managing the risk of not being accurate.
3. Prioritize & focus.
• A good practice at any level (from executive to individual contributor) at any thing (business, coding, personal life).
• Make sure you focus on achieving at least the top priority in it’s entirety by the target date instead of having advanced multiple priorities but never fully completing any. One thing done is better then 10 things almost-done, because almost-done is the same at not done.

I recently listened to the audiobook to Peter Drucker’s book entitled the Effective Executive. Here are my key take aways as to what makes an executive effective.

1. They ask what needs to be done?
• Do not ask “what do I want to do?”
• Concentrate on just one task, two at most, and never more than two at a time.
• Set priorities and stick to them.
• After completing tasks 1 and 2, instead of moving on to number 3 ask again what needs to be done as new opportunities may present themselves.
2. They ask what is right for the Enterprise?
• Not what is right for stock holders, employees, or themselves.
• A decision not right for the enterprise will eventually result in something that isn’t right for anyone.
• It won’t guarantee the right decision will be made, but failure to ask the question guarantees the wrong decision.
3. They develop action plans.
• Knowledge is useless unless you translate that into action.
• Before springing into action, plot a course of how you want to get there.
• Think about desired results, constraints, restraints, check-in points, and implications.
• The action plan is a statement of intention rather a commitment.
• It shouldn’t be ridged in that once sealed you’re locked in.
• It should be revised often as actions result in new opportunities.
• Time is the most scarce and valuable resource.
• Use check-ins to examine results vs. expectations, and revise the path.
• Without an Action Plan you are a victim of events.
4. They take responsibility for decisions.
• Decisions require an owner, deadline, those affected by it, those who need to approve it (or at least not oppose it), and those who need to be informed.
• People decisions (hiring and promotion) are one of the most important decisions.
• 1/3rd of people decisions have the desired positive result.
• The conclusion to make in cases where a people decision didn’t work out is that management made the wrong decision by not putting the right person in the right place (as opposed to viewing the person as “bad”).
• If someone is promoted into a job where they are underperforming, it may very well not be their fault as it wasn’t their decision to be placed in such a role. So if it’s not working out, offer them the previous job they held where they were successful. Odds are they won’t go for it, but it does send the message to the organization that it’s ok to take career growth risks.
• After making a people decision, set a check-in date to re-evaluate if it’s working.
5. They take responsibility for communicating.
• Effective executives make sure their action plans and informational needs are understood.
• Executives need to make sure that subordinates have access to the information they need.
6. They are focused on opportunities instead of problems.
• Problems can’t be swept under the rug, so don’t ignore them.
• However problem solving doesn’t produce results, it just prevents damage.
• Exploiting opportunity produces results.
• Changes present opportunities. For example changes in market conditions, economic conditions, consumer behavior, etc…
• Don’t let problems overwhelm opportunities. Find a way to promote opportunities over problems.
• Put your best people on opportunities instead of problems.
7. They run productive meetings.
• Make meetings work sessions (vs. a blab-a-thon).
• Decide in advance what kind of meeting it will be (press release, team meeting, etc…) as your preparations will differ, and what the desired result of the meeting should be.
• Terminate the meeting the moment the objective of the meeting  has been completed. Don’t introduce additional topics.
• At the beginning of a meeting, state its purpose.
• Follow up with meeting notes summarizing decisions, assignments, owners of each task, and deadlines.
8. They thought/said “we” instead of “I”.
• An executive only has authority because they have the trust of the organization.
• The needs of the organization come before the executive.
9. They listen first / speak last