“Where there’s muck, there’s brass”

hydra photo

Photo by Andrew Jian

I was reading this Ask HN post about a consulting arrangement that seemed a Sisyphean task. Here’s an excerpt:

I have been asked to consult a company in how they should speed up their development process.

 

Today the application which in the end of it all is a web application, consists of a lot of old ASP classic code, a COM+ bridge for being able to function within a mix of a lot of different .NET libraries written in .NET 3.5 (CLR 2). COM+ acts as a bridge between the two technologies.

 

The teams cannot compile code inside the development tools, it can’t debug unless they do it with some obscure hacks and workarounds and it seems that no one is really in control of what is going on in the core code base and no one really want to touch the original code base to clean it up and refactor/re-write it.

Seems pretty hopeless, right?  “Teams can’t compile code”?!  Unfortunately, this type of task is more typical of consulting engagements than not. After all, if there was a simple solution, why would the company have engaged a high priced consultant?  (If you are consulting and not ‘high priced’, well, that’s a problem, but a different one better left for another post.)

The comments on the post are interesting and worth reading. I left one, but wanted to expand on it. Now, I’m not familiar with the tech stack at all, but I am familiar with a large codebase (where large is relative to the size of the team supporting it–100K LOC can be large to two person team) with a lot of technical debt that was crucial to the business.  I have also consulted for years.

Whenever you are consulting, the first task is always to ascertain the real problem.  Hint–it’s often not what you were explicitly hired to do.  In this case, I’m guessing the real issue is that the web application needs to change to meet business needs, and that it can’t do so fast enough because of the accretion of complexity.  But a guess isn’t good enough, you need to find out what you are being hired to do–it could be you are being hired to provide cover to spend money to rewrite the app or to be blamed when a development team misses dates or to actually speed up compilation.

Then, you need to learn who wants the task done, and who is writing the checks.  They are sometimes the same person, but not always.  You also need to learn how these folks want to be communicated with, including method, verbosity and frequency.

Finally, you can start to dig into the (software) problem.  (This process assumes you are doing time and materials billing.)  Do a preliminary investigation and look at some of the following:

  • given the end goal, what are intermediate steps that can get you there?  How long would it take to get one or two of these steps?
  • are there third party solutions that can get you 90% of the way to solving the business problem–this can include framework upgrades?
  • are there subsystems of the current hand coded solution that are isolated and can be reworked with minimal impact on the system?
  • are there one or two huge issues that would be a relatively easy win (version control, big bugs, moving configuration from code to a database, etc)?

Prepare ballpark estimates on the level of effort to accomplish some of these.  After that, you need to sit down with whoever wants the task done and whoever is paying for it.  Present your options, making it clear that any time estimates are truly SWAGs.

Let them decide.

If they ask for a recommendation, be prepared to make one, but the decision must be theirs.  They have the business context to know how much to invest in this system.

After that, either withdraw or start executing against the plan you and the decision makers have decided on.

Simple, right?


Q and A: Unexpected technical issues when contracting

I got a question from a friend who is doing some freelancing.

Perhaps an odd question, but when you do web work and run into issues that are only showing up in IE browsers, do you bill the client for the extra time it takes to try to figure out how to make the site work on that crappy browser? I know the web developer(s) we used for the farm calculator [a project for which he was the client] bill for everything, even if they are redoing something they screwed up… but I’m curious as to your way of handling things like this. I want to be fair to my client, and myself!

This is a great question, and goes beyond just “IE browser” issues.  Here was my answer:

When I run into an IE problem, I will usually stop and ask the client if making it work perfectly on IE is really important to them.  It would be useful to have stats for IE on their website (or the broader internet: http://en.wikipedia.org/wiki/Usage_share_of_web_browsers ), so they can know if 10% of their users are on IE6 or 0.01%.  It also would be useful to have an estimate for how long it will take (as long as you’re clear that it is an estimate).

If I’m billing time and materials, and I’ve had this conversation, I absolutely bill the client, but try to keep them informed as to how long this is taking me.

If it is a fixed bid, then I might go to the client and say ‘I’ve run into this issue, for this browser, which is x% of your website traffic.  There’s solution A and solution B, but both of them are things I didn’t expect.  Can we talk about this additional work’.  If they say no, I grit my teeth and deal.

So, to make it more broadly applicable, if you run into issues that you didn’t expect, here’s my advice:

  • Stop work and identify the issue.  Don’t keep spinning your wheels.
  • Gather useful facts to help the client make an informed decision (IE browser % in the example above).  Include a rough estimate if you can, but make sure the client knows it is an estimate.
  • Talk to the client about the issue and find some kind of resolution.
  • If the resolution is you doing the work, then, if you are on a fixed bid, explain how you didn’t consider this particular issue and see if the client is flexible about paying for it.
  • If the resolution is you doing the work, and you are on a time and materials contract, then bill for the extra work.
  • In either case make sure you keep the client in the loop about time spent and schedule changes due to the issue.

Surprises come up all the time.  What is important is that you come to a fair accommodation with your client.


My experience implementing GWO for a non profit, part 2

I was finally able to get access to the wild.org server via FTP (previous cliffhanger resolved).  After cautioning me to be very careful (“please proceed with caution and help keep wild.org from blowing up…warnings from my IT guy”) Emily handed over FTP access.

I proceeded very carefully.

We had already had discussions about what we were going to vary to test the donation button.  Pictures, location of button, text of button, and text around button were the major variables.  One of the hard things about GWO is deciding what to test–the possibilities are infinite.  Even with our handful of variables, we ended up dropping some options and still have 100 variations to test!

Actually installing GWO was pretty easy.  The only wrinkle was the fact that the goal was a click of a button and not another page.  This post was helpful.  One item that that post didn’t cover was validation–GWO doesn’t let you start an experiment if the program can’t verify that the script tags are installed correctly.  Since we were doing a non standard install, I gimmicked up a goal page for validation, then added the goal tracking to the onclick event as described in the post.

So, the experiment is currently running on The WILD Foundation homepage.  It’s been running for about a week, and has only 1 non test conversion.  I worry that we are not testing big enough changes (a donate lightbox, rework the entire front page), but I think it makes sense to let the test run for a few weeks and see what kind of data we get.


My experience implementing GWO for a non profit, part 1

A few weeks ago, I went to the most recent BDNT and saw a number of non profits present.  It was very interesting to see the vast range of needs and technical experience across the twelve non profits who actually presented.  Everything from a small webapp project to any web presence at all to updating a custom php webapp.

Most did a good job of containing their request to something manageable, though one group did get asked “Do you need a super volunteer or an employee” by Andrew Hyde, I assume because their needs seemed so vast.  The answer: no employee would be hired :).

After pizza (thanks BDNT sponsors! ) I wandered up to the group that had piqued my interest the most.  The WILD Foundation had an employee (Emily) whose job responsiblities included social media, a blog, and actively engaging the online community.  This strategy had worked wonders for the foundation’s web traffic, but for online donations?  Not so much.  This was the challenge she asked us to attack.

The session was moderated by Derek Scruggs and there were lots of great ideas.  To paraphrase, you could see where someone sat by what actions they suggested.  I mentioned Google Website Optimizer (a tool I’ve been a fan of for a long time); marketing folks wanted to focus on the message; some people wanted to change button color.  There were about 10 suggestions at the end.  Derek and Emily and the group then ranked them by effort (mostly group input) and priority (mostly Emily input).  Then we assigned tasks to volunteers.

I volunteered to set up a GWO test for the donate button on the WILD.org homepage.  We’re going to vary images and text to see if we can drive greater click through to the donate page.  Eventually, it’d be nice to optimize the whole process, but the actual donation page and donation thank you page are hosted on a vendor’s server, so I’m not sure whether we’ll be able to.

It’s been a week or so, and I still haven’t gotten write access to the template so I can add the code.  There are a number of reasons, and I think they might be common to all technical volunteer efforts, so I thought I’d outline them.

  • Exploration of technology takes some time.  I looked at the GWO for wordpress plugins, and found that they didn’t quite do what we wanted.  I also nosed around the existing site and found which file to change in the theme.  And I suggested what elements we might want to vary and ran those by Emily.
  • Time was a big issue; both mine and Emily’s was generally lacking.  Since it was a volunteer effort, I squeezed it in around work that paid.  Emily had to do her job first too.
  • Trust had to be established.  These folks didn’t know me from Adam, and yet were letting me edit one of their primary faces to the world?  Emily’s IT guy was rightly concerned about this, and insisted on a website backup.
  • IT issues–I had trouble editing the theme files, and working through Emily (with this being neither of our highest priority) to resolve the IT issue (basically, getting me an FTP account) took some additional time.  As mentioned above, there’s still an issue of not being able to track the entire donation process (so as to optimize it) because the WILD foundation uses a third party donation acceptance service.  I think we can make it work but wanted to get a win and build trust without having to involve a third party like the donation acceptance vendor.

However, it’s all coming together.  Once I get GWO up and running, I’ll let you know.



Best Consulting Sales Pitch Ever

I heard this at a presentation about Mule (an enterprise service bus) at BJUG tonight.  The presenter, Rich Remington, at the end of the talk, put up a slide detailing a contest.  Anyone who emailed him with a use case that Mule might be able to help with won a chance at a free lunch and 1-2 hours of free consulting about the use case. You have to email him within 48 hours of the talk.
What a great idea!  Not only does he get to pick a use case that Mule can help with, he also gets a chance to pitch his services, and show his value to the client.  And he gets a list of possible clients–people who know about something about Mule and think they might have a problem Mule can solve.

The contest winner gets more than a free lunch out of it too–the chance to pick an expert’s brain for free for a couple of hours can be worth quite a bit.

Win-win, for sure.  What a great idea for anyone consulting in a specialized field!

Technorati Tags: ,


Body Shop Basics

Here is a great writeup on the basics of working for a consulting company (“body shops”).  These companies hire talent and then farm them out to other companies who have needs–either cost control needs or specific skill sets, or both.  This article talks you through some of the hoops around this process, what you can expect, and how to choose a consulting company to work for.
Scott also gives good reasons why people might want to be consultants, rather than employees:

A consultant is more free than a regular employee to circulate within his professional community and to take more jobs in more challenging environments. He can also get more relevant training. There’s no room in the consulting industry for wasting time — training must be good, and it must be for a good reason.

Some of the advice is a bit out of date (I doubt that “web development” would be considered a “new skill” anymore), but Computer Aid is apparently still around and the entire article is generally sound.  I’ve worked for a consulting company or two in my professional life, both as an salaried employee and as a hourly contractor.  I wish I’d read his advice then.

Technorati Tags:


Holiday gifts and why Moore Consulting sends chocolate

I’ve started a tradition of sending my clients a holiday gift. They all seem to appreciate it and I plan to continue for the foreseeable future. Sending these gifts is good for my business because the gift (in decreasing importance):

  • shows my clients that I appreciate them. I do good work, but lots of people do good work, and I want to show my clients how much I appreciate the opportunity to do business with them. Giving them a gift, no matter how expensive, pales in comparison to the amount I’ve billed them over the year.
  • strengthens the relationship. I’m selling not just the product of my time, but myself, and expressing gratitude shows another side of me that clean, well written requirements just can’t.
  • makes me stand out, at least among other software contractors. This is only anecdotal, but I have had clients remark on how few of their contractors send any kind of gift or card.
  • reminds my clients about me–some of the recipients might have not heard from me in months, so the gift is a reminder of my services.

It’s also good for me, for the following reasons:

  • Gratitude feels good
  • It’s fun to pick out gifts
  • Going over invoices to get addresses serves as an excuse to review all the work I’ve done, as well as goals I may or may not have accomplished.

In 2008, I picked chocolates from It’s Only Natural Gifts, because I wanted to support a local company and their product looked good. They made it easy; all I had to do was give them a spreadsheet with client addresses, messages and type of gifts, and a credit card number. I also sent a card to a client that I did a small amount of business with.

I recommend doing this for your clients next time the holidays come around.

Technorati Tags:


The Gift Of Negative Feedback

“Success is a lousy teacher. It seduces smart people into thinking they can’t lose.” – Bill Gates

One of the hardest things to do as a consultant is to admit I screwed up. After all, I’m brought in to solve problems that the client could not or would not address. I’m paid a lot of money (compared to employees, not hedgies). I have a reputation to uphold–that’s how I sell myself.

But, of course, I’m human, and make mistakes. One of the greatest gifts a client can give me is honest feedback on how I erred. It’s a gift because

  • I learn something
  • it takes the client’s time
  • it takes the client’s emotional energy
  • it would be so much easier for the client to just say nothing and not use me again

Did you catch that? Instead of the usual transaction which is trading my knowledge and time to the client for money, the client is giving me knowledge.

It’s precious.

But don’t think it’s easy!

I screwed up recently and was given the gift of negative feedback. My first instinct was to reach for the requirements, or review emails, or figure out some other way to prove to the client that I was not in the wrong.

But the simple fact is that, if the client isn’t satisfied, a consultant is not in the right (I’m leaving aside clients that you should fire). It’s easy for me to think I’m selling hours and knowledge, but what I’m really selling is satisfaction. I don’t want to take a red cent from someone who isn’t satisfied with my work.

So, I had to sit and breath, walk and think, and just generally process this gift. After having done so, I communicated with my client, re-iterated my goal of his satisfaction, and proposed a compromise on my invoice. He was happy with that and we went on to do another project. I’m hoping he’ll consider me for more work in the future, but even if he doesn’t, the lessons I learned were well worth the cost of the compromise.


Squid cache log configuration thoughts

I have found that debugging squid, the excellent web proxy, is difficult.

I believe this is for a number of reasons, but primarily because I’m a developer, and just want to get squid working. I’ve found that I do this with a lot of tasks that are required of the small independent developer with time pressures–CSS/UI development, database design, system administration. All these are things that can be done well by competent specialists, but my clients often don’t have the money to hire them, or time to find them, so they get me. What they get is not in depth CSS knowledge and in depth knowledge of the entire user interface problem domain, for example. Rather, clients get my ability to figure out the problem (based, to a large extent on internet knowledge and to a lesser extent on my deep understanding of web applications and how they should behave) and my tenacity to test and test again to ensure that corner cases are dealt with. It’s a tradeoff.

Regardless, squid is hard for me to debug, and I found this page which lists all the options for the cache.log debugging parameters useful. However, not all that useful–‘client side routines’, number 33, apparently includes squid ACL parsing. Rather, I’ve found the Squid FAQ to be the single most helpful document in terms of my understanding squid enough to ‘get things done’. However, this time I ended up viewing the access log of my http server, while deleting my browser cache multiple times, to confirm that caching was set up the way I thought I had configured it.

Technorati Tags: ,



© Moore Consulting, 2003-2014 +