Recharging the Battery

One of the ‘joys’ of having my own business is that I’m always on-call and there are times I’m answering emails on a Saturday night.  Most of the time, it’s no big deal but it can become exhausting without a break.  This is why I need to take time off and recharge my batteries.  So should you.

Carol and I did that last week with a vacation in the Caribbean.  We had a lot of fun and got a chance to recharge our batteries and get away from work (and US politics).  And even though we weren’t technically working (I consider coding to be the real work), we did talk about our business and those things we are grateful for.

One thing we are extremely grateful for is the fact that we can take off for a week without feeling guilty.  That got us thinking on why is it so hard for consultants to take time off.  It’s not too hard to figure out but here are a few items from our list (sadly the list got a Bahama Breeze spilled on it and thus couldn’t be saved for posterity, but here’s what we remember).

If you’re not working you’re not making money.  So true for consultants, but my advice is to try to develop multiple income streams so you can make money without doing consulting.  We have our developer products (ARGen and Shorts are our big ones) and without any work on my part we sold some last week.  We also have our Xojo Training videos that are income.

Having that one big all consuming project.  A lot of Xojo consultants I’ve known over the years have that one big client that consumes nearly 100% of their time.  We have multiple Xojo developers and while we can do big projects that involve all team members, it’s pretty rare.  This means that our income (and risk of losing it) are spread across multiple projects/clients.  For us, projects come and go, and that means there are times when one or two of us get to work on internal projects but our income levels stay consistent.

It’s all on you.  Solo consulting stinks because it’s all on you.  I can’t tell you how many solo Xojo consultants I’ve seen come and go in my fifteen years.  Doing it all by yourself is tough and sort of ties into the one, big, all consuming project from above.  You only have so many hours in the week to code and if you don’t have help you still have to take time out for marketing, sales, and developing multiple income streams.  It’s just not possible for solo developers to be spread that thin.

Do you have a job, or do you have a business?  Over the years I’ve had multiple solo consultants chastise me and tell me that I’m just ‘training my competitors’ with my multiple employees.  Sure, that’s always a possibility, but is it probable?  So far, they haven’t and my thinking is that if they really wanted to have their own business they’d probably already be doing it without my training anyway.  Having and running a business is not the same thing as having a job.  Plus, that type of thinking comes from fear and I’m confident enough in my own abilities and experience that it simply isn’t a concern.

Consulting rates are too low.  I’ve talked about this multiple times but too often someone new to consulting will take their last real-world salary and figure out their rate from that.  This is absolutely the worst thing to do because as a consultant you don’t have a job you have a business.  You need to have a rate high enough to pay for health insurance, retirement plans, and to pay yourself during your vacation escapes each year.  It is your responsibility, as a business owner, to calculate what rate that is for you.  If you want to know my rate send me an email and I’ll gladly tell you but I will also say that if I was still a solo developer it would be higher because I can only code so many hours in the week.

You must recharge your batteries every now and then.  Without that you become inefficient and run the risk of burning out and you’ll be sending an unhappy client to me to take care of their project.  Don’t laugh because some of my best long-term clients came from a solo Xojo developer that had to leave consulting for one reason or another.  Some left because they were charging too little to pay for health insurance, retirement, and to recharge their batteries on a consistent basis.

So what do you do to recharge your battery?  And why do you think many people fail as solo developers?

Consulting Red Flags

The one absolute truth about consulting is that if you’re not working you’re not making any money.  The corollary to this truth is that you are either 100% busy or 100% not busy.  This is especially true if you are a solo developer.  It is very hard to turn down projects when they come your way but I’ve found that there are times when you should.

I get it.  Really, I do.  If you’ve been idle for longer than you’d like and money is starting to get tight ALL projects start to look good.  Don’t take the project because you need the money.  Take the project because it’s a good fit, it’s interesting work, and you think the client will be a good partner.

In the world of make-believe this is the way it should be.  In the real-world you don’t always have those options.  Plus, it’s really hard to figure out if a project is going to be a good one or not.  Here are some of the red flags I’ve come to recognize in fifteen years of being a Xojo consultant.

Other Peoples Code (OPC).  Code written by someone else is always a red flag.  We write code a certain way and if any of our team work on it we can rest assured that certain things will be done (naming conventions, comments, etc.).  No such guaranty with OPC.  It’s way easier to start from scratch but with most OPC projects you don’t have that option.  So you start with a level of uncertainty and having to decipher not only the coding style but often times the intent of another developer.  Learning someone elses code stinks.

Project complexity.  When I’m asked to join an existing project I try to look at how complex it is.  If it’s really complex I hesitate because I know it will never get less complex.  In many cases the original developer tried to be clever to solve some (real or imaginary) problem and while solving it completely overlooked a much simpler way of doing things.  Plus, if it’s not one of your core competencies it might not be a good fit anyway.

Another item under the project complexity red flag is excessive amounts of documentation.  From experience, most projects can be summed up with a page or two of high level description and then a dozen pages of important detail.  When the client sends you a very long document with high levels of detail you might be getting yourself in other your head.

Of course the flip side of that is clients that send you a paragraph or two of their idea.  In those cases we have to draw more information out of them, and depending upon the size of the project, we might actually charge them to write their specifications for them and let them get some competitive bids from other developers.  I think the lack of detail says they haven’t done enough homework on what they want and need.

Toxic teams.  Another issue with joining an existing project is trying to figure out if the team is toxic or not.  The existing developers will always have their own habits and you, as the consultant, need to try and match theirs.  What if those habits are silly?  I’ve seen teams that require a comment for every line of code.  I’ve seen some teams that disdain any comments under the guise that code should be ‘self commenting’.  Is there a team member who’s the ‘smartest person in the room’ and everyone else has to put up with it?

Project savior.  I can’t tell you how many times I’ve been asked to look at a project started by other developers and the project owner is desperate for it to get done.  In these cases they’ve spent a LOT of money with a developer and gotten poor, or no, results.  You have to ask yourself a few questions.  Was it the developer being incompetent, the owner being unreasonable, or both?  If you take one of these projects you can either be the hero by completing the project, or you can be the goat for being just as incompetent as the original developer.

Project owner/developers.  I’ve found that working with project owners who are also part-time developers also can be a pain to work with, but not always.  The ones that come to me realizing that creating an application isn’t easy and requires time they don’t have and knowledge they don’t have time to acquire tend to be okay.  Those that say it should be ‘fast’ and ‘easy’ for someone with your skills have their expectations set too high.  Software development, in many respects, is more art than science.

Always complains about cost.  Every client wants their custom software done cheap, quick, and on time.  The industry joke is to pick two of those qualities.  Software development of custom software isn’t cheap, nor is it quick in most cases.  If they balk at the initial estimate it probably won’t get any better.  They certainly won’t like any change orders.  We had one prospective client ask us three times, over the course of a year and a half, what the price was going to be to complete their project.  I don’t know if they expected our price to go down, or what, but eventually they found a developer to do their project at the price they wanted.  And then had the audacity to come back six months later then that developer couldn’t deliver.

Been through many developers.  Perhaps my biggest red flag of them all is when someone comes to us after going through several other developers.  Listen to their complaints about the other developers.  Were they too slow, did they charge too much?  I’ve even asked for permission to contact the previous developer to get the news from the developer perspective.  The community is small so there’s a good chance I know them and I know I’ll get the developers perspective.  Use those connections if you can because you might discover some useful information about the client and the project.

Just because you need the work doesn’t mean you should take every project that comes your way.  Be selective because you’ll avoid some heartache and probably enjoy your work more.  What red flags have you developed over the years?

Naming Conventions

If you don’t have standard naming conventions in your Xojo (or any other language for that matter) project you need to start NOW.  I mean it.  Open your IDE of choice and start looking at your variable names.  Can you tell at a glance what type of variable it is?  Better yet, can you tell what it does?  Or do you have a bunch of x, i, y, and z’s floating around in your code?

What about your TextFields?  Do you name them so you can tell their function or do you simply use the default name that the IDE gives you?  How do you tell the difference between TextField1 and TextField2?

Literally, the first thing I do when handed an OPC (Other Peoples Code) project is to look at the control names.  If I see TextField1 and TextFieldX I will almost always turn the project down.  But if I see txtName and txtAddress I know that I can figure out the code without constantly having to look at the Layout Editor.  The point is that controls are referenced in Xojo code all the time so if you’re naming your controls so that their function is obvious, the code will be obvious too.

The same goes with variable names.  I will prepend arrays with ar so that an array of MyClass will always look like aroMyClass.  My dictionaries always have dict in the front.  Colors always have c prefixes and so on (see chart below).

Do I use the occasional i, x, y and so on?  Absolutely, but they are throw away variables that are inevitably part of a loop of some sort.  If I’m using that variable for any other reason I will always name it something useful.

Variable names are important.  Rarely will you see me using iTemp as integer.  Instead, I’ll use iTempIndex which will at least tell me something about the variable.

I dare you to look at a project you did a year ago and open up any random method in it.  Can you read the code without referring to the Layout Editor?  I know that I’ve refined my own coding standards because of this.  If you’re not learning from your past mistakes why keep doing what you’ve always done?

I can hear some of you now.  Standards…Pft!  I don’t need no stinkin’ standards.  Think again.  I’m not here to tell you what those standards are just that you have them and that you are consistent about them.

Do what makes sense to you.  I looked at hungarian notation ( and I can see why people call it a different language.  While I’m sure it has many fine qualities it seems to make more work for me in figuring out what the variables are doing.  It’s way too complicated for Xojo.  For me, at least, simpler is better.  Plus, I’m not sure that a strongly-typed language like Xojo is in need of such strong naming conventions.

Using naming conventions for your controls and variables is an easy way to simplify your life and your clients’ life (if you’re handing code over).  Remember, you’re not just coding for the here and now, you’re coding for someone that will look at the code 6 to 12 months from now.  That someone might just be you!

Below is values right out of our new developer introduction document:

Variable Prefixes
Datatype Prefix Example
string s sName as string
integer i iCnt as integer
double d dAverage as double
dictionary dict dictNames as Dictionary
date dtm dtmModified as New Date Assumes I care about the time
date dt dtToday as new Date assumes I do NOT care about the time
class reference o oMyClass as new clsMyClass
color c cHighlight as color
folderitem f fPic as FolderItem
private property m miCnt as integer
boolean b bVisible as boolean
memory block mb mbBuffer as MemoryBlock
window win winMain
class name cls clsMyClass
array ar arsNames() as string ardAverages() as double aroMyClass() as clsMyClass
Control Prefixes
Control Prefix Example
Pushbutton btn btnSave
Label lbl lblCaption
Listbox lb or lst lbPeople or lstPeople
StyleGrid sg sgPeople
TreeView tv tvSections
TextField/TextArea txt txtPassword
CheckBox cb or chk chkEnabled
BevelButton bb bbSelect
ComboBox cbo or cmb cmbUserType
PopupMenu pm pmState
ProgressBar prog progUpload
Scrollbars see example common practice to use vScroll and hScroll
Radio Buttons rb rbOption1
Canvas cvs cvsGraph
TabPanel tab tabMain
Toolbar tb tbMain
PagePanel pp or page ppSection
Menu menu menuPopup
Container Control cc ccDetails

You Have a Contract, Right?

Writing software for others can be a tricky profession.  The client often has totally unrealistic expectations on how software development works.  They give vague requirements (or none!) and expect you, the developer, to read their mind and produce an awesome application.  And therein lies the problem, because there’s a wide difference between their requirements (or lack thereof) and the finished project.  A handshake and a verbal agreement just isn’t good enough – You need to protect yourself (and the client) with a contract and spell everything out.

If you don’t have a contract already, my preferred place to begin is by going to Docracy ( and looking up contracts.  These forms aren’t perfect, but they’ve been looked at by lawyers, and in-lieu of hiring your own lawyer, a heck of a lot cheaper.

The basic contract has little over a dozen sections.  I’ll just highlight a few of the sections that seem to grab peoples attention.

A payments section is obvious.  It gets into the details of how you’re getting paid.  More detail is good.  What’s the rate?  How long is it good for?  Is it a fixed bid?  What is the payment structure?  Do you have a separate rate for bug fixes and for how long?  When can you revisit rates?  Do you take check or credit card?  Do you have a fee for taking credit cards?

The expenses section should detail everything that you are paying for out of your own pocket (like computers, development software, etc.) and what you expect the client to reimburse you for.  This could include travel expenses, special services, software, or plugins required for the project, postage and courier services or any number of legitimate things.  The point is that you need to document it!

One section that has caused me some issues over the years was the intellectual property ownership section.  Every client wants to own the code you’ve written and this section gives any patents or trade secrets developed for the project to the client.  I have, as many consultants do, a stable of controls and classes that I reuse on nearly every project which really can’t be the clients’ property when the project is done.  This is where the consultant’s materials section comes into play.

Consultant’s materials are the tools, or pieces of code, that were in existence before the work began that you use to get the job done.  You can give the client nonexclusive rights to the software with some exceptions (spelled out of course), or you can attempt to retain the rights to your own software.  Regardless, this section should be read carefully so that you and the client thoroughly understand the implications.  It has been my experience that this section almost always needs an edit or two to satisfy everyone.

A lot of clients also require a confidentiality agreement section that says that you won’t talk about your work for the client to others without permission from the client.  Sometimes they also want a non-compete section stating that you won’t work on similar software for a certain number of years.  Make sure that you understand the implications of these sections because it might mean you lock yourself out of an industry!

All of the above is fairly generic and is applicable to nearly all contracts.  In my format, the exhibit document is where a bulk of the details occur.  Here is where I list my deliverables, the client deliverables (I don’t like doing graphics so I usually require that the client do them), a listing of any requirements that I’ve received so far (referencing emails and other documents if need be), assumptions that went into the bid, payment schedule and amounts and milestone dates.  As you can image, the exhibit may be much larger than the rest of the contract.

In the client deliverables section, I always state that the client is responsible for final application testing and that they are responsible for end-user support.  The reason that clause is in there is that a client assumed I was doing all the testing and was going to perform end-user support.  This is why writing everything down is so important!

One of the assumptions I generally add into my Xojo projects is that Xojo can actually do what I, and the client, assume it can do.  I only had one issue ever come up and because of that assumption we were able to negotiate a slightly higher contract price to purchase a pricey third-party control.

In the exhibit I add a section that describes how long after the final sign-off I’ll fix bugs for free.  I also state the rate for the following year on program changes (new functionality, not bugs) and when I can renegotiate pricing.  This section can be contentious.  I’ll fix true bugs for a long time, but a lot of times the client doesn’t understand what a bug really is and how it’s different from their poor (or nonexistent) requirements.  If you find a problem client, this will probably be one of the areas that causes you grief.

There’s a lot of information that will be in your contract.  It’s designed to protect you and your client against poor assumptions.  It provides a way for you to handle the client and set their expectations upfront.  In the long run, a good contract will be the roadmap of your projects.

Why have a contract?  Because not having one may cost you  a lot of money.  I turned down a project a few years ago because the prospective client balked at having to pay money up front.  In indignation he claimed in 30 years he’d never paid anyone up front.

He then proceeded to go through the rounds of contractors and they all turned him down for much the same reason.  Finally, he found a developer that was looking for some extra money but already had a full time job.  He did the work (without a contract and without any up front payment).  And, as you can imagine, the client shafted him in the end.  Said that it didn’t work as promised so therefore wasn’t going to pay.  The client was full of it because he walked away with the source and never looked back.

The developer lost thousands of dollars and had no way to enforce it since he didn’t have a contract in place.  Even having a contract won’t stop a client from not paying but at least with a contract the developer could have gone to small claims court to recover some of the money.  No contract meant no such recourse was available.

I think we all have contract horror stories.  Have any that you’d like to share?

Open Letter To RS

Dear Real Software,

Thank you for a wonderful product.  It has served me and my clients well for over a decade now.  I can think of no other product that is as easy to use yet as powerful and flexible as Real Studio.  It really is a great product and I have no problems recommending it to others.

I have been critical of Rapid Release Model in the past and will probably continue to do so in the future.  I feel that in too many cases incomplete features and documentation have been released simply to fit the schedule.  I have advocated for fewer releases or releases that stagger bug fixes and new features because I have been bitten, too often, by needing a bug fix in a new release just to be bitten by a new bug somewhere else in the product.  It’s very frustrating for me and my clients.

Unfortunately, at this point in time, we are experiencing the opposite effect.  You see, you have been telling us for over a year that we need to be testing Cocoa because it’s the future.  We’ve taken this to heart because we don’t care to get caught with our pants down.  In addition you’ve also told us that bugs in Carbon, unless critical, won’t be fixed.  This leaves us between a rock and a hard place for our Macintosh builds because we have projects (for paying clients) that can’t be built using Carbon because of bugs, and we can’t build for Cocoa because of Cocoa specific bugs.

We have similar issues with Web Edition apps.  We have a number of very critical bugs that are affecting our delivery of web apps to our clients.  Sadly, what makes this situation hard to deal with is that those bugs are marked as fixed and are only awaiting a new release.

We all know that the goal is to have the 2012 Release 1 be a 100% Cocoa Mac build.  We also know that it is a completely redesigned IDE.  Both are laudable goals and I can only imagine the complexity of managing both of those projects simultaneously.

Real Studio Release 4 was released the week of December 5, 2011.  The three dot releases fixed some hugely critical bugs but contained just a few changes.  I understand that all hands are on deck to get the new IDE up and running and Cocoa polished.  No one is denying that it’s not a huge job to undertake all that at the same time.  I question, however, if you really have the resources available and the proper planning in place to accomplish these goals in a timely manner without understanding the ramifications to your customers.

It’s now been 120 days since the last major release.  Frankly, I don’t care about the 90 day release cycle but it leaves a foul taste in my mouth when you tell us to use Cocoa because you need more feedback and then stick us with a release that has bugs in both Carbon and Cocoa.  Unfortunately, there is no end in sight as there is no release date set for 2012 Release 1 and, as far as I know, R1 is not in beta testing yet.

This delay is starting to be intolerable.  Your failure to plan and execute this transition properly is starting to cost me.  So far, my clients have been patient.  The really large projects are still on schedule but that’s about to end as Web Edition and Cocoa bugs WILL cause them to stop dead in their tracks.  Do you plan on paying my salary and my employees while we wait on you to release a working and stable version?  I’m certain that my clients won’t be willing to pay for projects that don’t work because of framework bugs.

Here’s my fear:  You’ll release a new IDE with all of the Cocoa and Web Edition fixes but because you’re hurrying it through the testing process (because we’re all bitching for bug fixes) it will not be usable.  If that happens I am doubly screwed since I have zero options.  I can’t go forward and I can’t go back.  I see this as a lose-lose situation for me.

I urge you to reconsider the Cocoa and IDE redesign in the same release.  Let us, your loyal, paying, customers get our bug fixes so that you can continue working on the new IDE.  I realize this change will greatly impact the schedule of the IDE.  I also realize that retrofitting the newer framework into the older IDE is also a LOT of work if not extremely difficult.  However, if going back to an R4 update is faster and more stable than the new R1 IDE then I say do it and I will applaud the decision and defend the decision to the end.

I know this letter probably won’t go over well but I’m looking ahead and getting nervous.  I know you’re working as hard as possible but perhaps it’s time to rethink the strategy and go a different route.  Engineering is about planning and adapting to changes.  There is no shame in doing something different.

I hope I’m wrong and things fall into place.  I’d love to pen a post saying thanks for a great release saying that all of my developers and clients are happy.  I see many things that will make that hard to do.  I am nervous and nervous customers are a bad thing.

Anxious and concerned,

Bob Keeney

BKeeney Software Inc.

No Face-To-Face Meetings Requires a Different Skill Set

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?

Registration Systems For RB

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?

Is It Time To Add Staff?

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?

Thoughts on Management vs Programming (i.e. Wide vs Deep)

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?