BKeeney Briefs

I was reviewing this years client list and the work we’ve done this year.  We have a lot to be thankful for and we really appreciate their business and like to send them a small token of appreciation during the holiday season.  We hope they come back for more work and the gift, trivial really, is just a way of saying thanks.

I started thinking about our clients.  With the exception of a handful, most of them are not in the Kansas City area.  Heck, most of them aren’t even in the Midwest.  So what this means is that we never see our clients in a face-to-face meeting and have to rely upon phone calls (both traditional and via Skype), emails, instant messages, and the occasional screen share or video conference.

This makes managing a project harder in my opinion.  There is so much information that gets passed when you’re sitting across from a person that you’d be hard pressed to write it all down.  It’s hard to get that same level of info electronically.

I get a chuckle when I hear about companies looking to offshore their development work to developers in developing countries.  Sure, it’s possible and you might be able to save some money but there’s a hidden cost.

In an Cutter Consortium survey Link over 20 years and 8000 projects they found that offshore projects reduced the cost of projects to $3.2 million versus the $3.5 million it typically cost by doing it on-shore.  From a time perspective the on-shore project took 12.6 months and the offshore took 9.6 months.

The real kicker is that the defect rates for offshore projects were an incredible 7565 versus the 2702 for onshore projects.  So even though the offshore project cost less and took less time, the company had to fix nearly three times more defects.  In the long run I’m not sure the offshore projects saved anything.

In the same study Agile methodology came out looking like a winner.  The average agile project took 7.8 months with a cost of $2.2 milling with a defect rate of 1372.

Last summer we worked on an agile project.  It takes some time getting used to but after the initial learning curve the project went very fast and the client was very happy with the results.  If you have a big project you should probably think about using agile.

I apologize for digressing from the main topic.  Certainly one of the of biggest challenges with a long-distance client is communication.  I suspect this is why the offshore projects have higher defect rates.  Everything needs to be written down and communicated – mostly via email.  Throw in cultural and language differences and you have a recipe for misunderstandings (if not outright disasters).

A couple of things that I’ve learned is that the communication skill of each client is different.  Some can handle an email with a list of questions.  Others can’t so you end up with single point emails.  Email management is a must!

We use a bug tracking system and encourage our clients to log in and use it.  Most get it and love being able to track what’s been fixed and what hasn’t.  Others just won’t use it (despite regular prodding) and resort to emails.  Depending upon the size of the project, it might just be easier to transcribe those emails into your bug tracking system.

Long-distance clients need special attention.  They need reassurance that you are really working on their project.  For some clients we do a 3P report where we report on Progress, Problems and give the Plan for the upcoming week (sounds sort of agile, no?).  With the web becoming an integral part of our lives and business, learning how to work with clients from anywhere in the world is an important skill.

How do you deal with long-distance clients?  Do you try to have a face-to-face meeting with them?  Do you think you do anything special for your clients?

Product registration and licensing systems is a fairly common call for help on the REALbasic forums.  I know I’ve rolled my own registration system and used various commercial solutions over the years.  In fact, we came up with a solution that works with desktop apps using a licensing system meant for servers.  That solution has worked well, but time goes on and what was good for years might not be such a great idea now.  Software grows old and stale and new solutions are born.

To me it seems that there are a couple of issues to deal with.  The first is keeping casual piracy down to a minimum.  I have no doubt that someone determined enough can pirate any piece of software.  It’s just a fact of life-get over it.  This means that if someone pays for the software they can’t post the registration code and have it go all over the internet.  Or if they do, it quickly gets squashed and it’s no longer valid.  Another consideration is that I don’t want to piss off my good customers because my licensing scheme is so draconian (I’m looking at you Microsoft).

The second part of the equation is getting paid.  People want to use PayPal or their credit card (and occasionally checks via snail mail) but setting some of that up on your own is a pain.  PayPal is probably the easiest but I know there are segments of the population that refuse to use it.  Plus I want my money sooner rather than later.  If someone else is handling my money will I have a waiting period or minimum balance before I get to see the money?  Is it an automatic transfer or is it via check?

The third part of the equation is administration of the system.  How easy/hard is it to add coupon codes?  Can I get detailed sales reports?  How easy is it to issue to refunds?  Can I email customers with news?  And do those customers have an easy way to opt-out of future emails?  Can customers retrieve their licenses without manual intervention?

The fourth part is how easy/hard is it to integrate into my application?  Do I have to come up with my own registration code algorithm?  How do I convert existing customers over to the new system?  Does it work on Mac, Windows and Linux?

So I want it good, reliable, cheap and fast!  No pressure there! 

Kagi and eSellerate seem to be two fairly common solutions.  Both take a chunk of money from the sale price and until I saw the Apple app store I thought their commission was a little high.  Perhaps it’s worth the hassles leaving all of the server details to someone else (after having dealt with server issues in the past six months it might be worth it!)

FWIW, I used Kagi several years ago and was not very impressed with their responsiveness to support issues.  I also found their interface for making a webstore to be very clunky.  Hopefully they’ve changed, and if so, I’d love to hear about it.

What are you using for registration systems?  Do you like it?  Was it easy to integrate into your application?  Has it helped income or hurt it?  What sort of problems have you had?

My company has been super busy with consulting work.  Old clients keep bringing us new work.  Potential clients are asking for quotes and surprisingly, our VB6 to RB analysis program has been giving us a lot of leads in the past month or so after being quiet for months (perhaps the website redesign had some affect).

We have several older products that need updating.  We picked up several new products that we need to maintain and make enhancements to.  We have new products in mind that we can’t even begin to think about because of the work backlog.

In addition, we need to have some time to absorb and learn some new technologies.  We’ve started on iPhone development but, like most technologies, you have to immerse yourself in it for at least a month to really understand it much less be proficient at it.

So, the question is, is it time to hire an additional developer?  That’s a scary thought because I’d hate to hire someone and six months from now say, sorry, we don’t have the work for you.  That’s beyond unfair it’s just wrong.

Some friends have suggested that I just get a contract programmer.  I do happen to know a few RB developers after all.  My big thing is that this is my business – my baby if you will.  I want someone invested emotionally in the day to day workings of the company and seriously interested in having it prosper.  If the company prospers so do the employees.  So I want someone local that I can meet face to face with on a regular basis.

So what do you think?  What’s your advice?

I ran across this blog today titled Wide vs Deep and it got me thinking (which is always a scary thought). The blog is about how programmers are promoted to managers even though the thought processes are different. Managers are wide and shallow and programmers are deep and narrow.

While the article specifically references programmers that get promoted to managers I think it’s appropriate to talk about it since many of us are small business owners.  That means that we don’t have managers and programmers.  Forgive my poor English when I say, “We is it.”  So how do those of us that do both deal with being the programmer and the manager?

I’ll start off with a little bit of my background since I think it explains a lot about me and how I think about things.  I grew up in farm country in rural Illinois.  My role models growing up were men that with bailing wire, chewing gum and a welder could fix any piece of machinery under the sun.  None of them were specialists in anything and had a very wide grasp of reality.  They were tenacious and didn’t give up.  I think that’s the nature of being a farmer.

I attended an engineering college on the south side of Chicago just blocks away from Comiskey Park (and the Robert Taylor homes but that’s a different story!) where I earned a degree in electrical engineering.  Going to a private school was a struggle financially so I co-oped, did internships and worked my way through school in six years.  My education ran very deep and narrow in areas related to electrical engineering although you can argue that electrical engineering touches many areas of engineering (thank you very much for that lovely class called thermodynamics, by the way).

By the time I had graduated I had two full years of experience as an engineer and landed a great job solely because of my experience.  In my new job working in an industrial environment (steel mills and foundries) there was “the problem.”  The problem might be simple or complex, but it was my job to figure it out.  One day it might be fixing a glitch in a PLC program, looking at the circuitry of a steel hardness testing station, programming a new labor saving device or doing the load calculations for a new transformer.  The solutions involved researching the issue, evaluating the solutions, engineering the solution, getting the approvals to do it, and then do it!  I would call that the funnel approach since it starts wide and narrows down considerably towards the end.

As a software developer and the owner of a business with programmer employees I find myself being torn between being wide and deep.  I can’t do both at the same time and I can’t switch between the two quickly or easily.  When I’m in management mode I just can’t go deep without a transition period.  Thankfully, going from programmer to manager is an easier process even though it’s frustrating not being able to finish what I was working on.

From a project management standpoint I don’t need to know the details of the class/module that is being used or modified – I just care that there’s a solution.  But the programmer is concerned with the implementation details of that class/module.  They couldn’t care less (most of the time) if the customer is 30 days past due on an invoice or what the next project is.  They’re too deep into the details to care and, besides, that’s a “management problem”.

If you’re the sole developer in your business, it’s all too easy to miss the details or go too deep into the details too soon.  If you’ve ever been thinking about the code at the bidding stage and you’re designing classes or thinking about the details of how you’ll implement the project then you’re probably too into the details too soon.

Likewise, when you’re creating your bid, you can’t just guess at how long or much money a project should be.  You need to determine some of the details and maybe do some proof-of-concept programming before creating the bid.

So it’s not just as simple as being wide or deep.  You have to manage the process – especially if you’re on your own.  Here are some recommendations you can try.

1    When you first start looking at a project don’t go too deep at first.  Write down all of the major areas you (as the programmer) will need to take care of without getting into implementation details.
2    Identify those areas that you need to research and do some proof-of-concept programming.
3    Do your research and proof of concept programming but do NOT polish it.  Do not spend a lot of time on it, but also code like you’re coming back to it later (which hopefully you will if you’re awarded the bid).
4    Stop and re-evaluate your original major areas and assign values to them and finish your bid.

Once you have been awarded the work, you can use the research and proof-of-concept coding as a starting point.  You can start going deep into the details and code but keep in mind that the management of the project is not over yet.

As you gain experience it becomes easier to estimate.  You just ‘know’ that it takes a certain amount of time to do some task.  You’ve done it before and you know the pitfalls and complications that can arise.  (Shameless plug coming)  Use a product such as Task Timer to track your time.  If you don’t know how much time you spent on projects in the past how can you accurately estimate similar projects in the future?

In a future post I’ll talk about how to climb back out of the pit of details.  So what are your thoughts?  How do you avoid going too deep too soon?