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?

The Nov/Dec 2007 Issue of RB Developer is out. My new column, titled BKeeney Brief's, is now a regular feature.

This topic for this issue is finding work. Please let me know if you agree or disagree or have any other options for finding work.

Visual Basic 6 is arguably the most common development language on the planet. It's low barrier to entry and easy-of-use and its extensibility make it ideal for many non-programmers to make a 'working' application that does exactly what they want.

VB6 is no longer supported by Microsoft. This is forcing many developers into the .NET environment which is not as easy to use and many would argue that the language is no longer 'basic'. So what are companies that have dozens of VB6 applications to do?

Let's also add to the mix that Apple has doubled their market share with very slick computers. Linux has very vocal and loyal supporters. All this means that companies that were once Microsoft-only now need to convert their VB6 code to something else. Whether that something else is .NET, Java or REALbasic is somewhat irrelevant because every choice is going to involve pain (money, training, time, etc).

Converting from VB6 to REALbasic should be a no-brainer, right? Wrong. While they both have basic in the name, they really are completely separate languages, each with their own set of peculiarities. Yes, there are many similarities between the languages but that doesn't mean it's easy.

REAL Software has had the Visual Basic Project Converter (VBPC) for a while and was last updated in early 2005. It's free for download. I would recommend that you don't even bother - you're better off converting by hand. Hey, you get what you pay for, right?

I find it inexcusable that REAL Software has taken over 2 years to release an update to software that might very well be the first thing that VB6 developers see when evaluating REALbasic. Here's a very brief list of what it doesn't do:

• Windows and controls are not converted to the proper dimensions
• Enums not converted
• Structs not converted
• The converter mangles code with no errors

There is one commercial product to VBPC and that's VB Convert! by AYB Computers. Its price tag is a very reasonable $50. Even if it only saves a little time it's worth the money.

VB Convert! does a good job of converting VB6 forms to RB windows as long as you are using the standard Visual Basic controls. If you're using 3rd party controls you'll at least get a canvas subclass in the proper position.

The code conversion is better than VBPC but keep in mind that there are just some things that won't convert very well. One such item is file I/O. VB6 is a product of the early 90's and is not OO in most areas. REALbasic file I/O is pure OO. Only a programmer can objectively convert from VB6 to RB at that point.

VB Convert! will convert enums and structs properly. They also have a variety of options that the VBPC doesn't have like forcing pushbuttons and editfields to a certain minimum size and converting a ADODB recordset AddNew method to using the REALbasic DatabaseRecord class.

You might think that I'm being easy on VB Convert!. We, as a company, thought long and hard about creating a VB6 converter. At first blush everything seems easy but then you get into the exceptions, and VB6 oddities, and all the 3rd party ActiveX controls and you start to realize that it's a HUGE problem. For a version 1.0 product AYB has blown away VBPC in terms of usefulness.

In the long run, no 'converter' will do all the work for you. If you think you're going to select a VB project file, run the conversion process and then hit the RUN button in REALbasic you are sadly mistaken. The conversion process is just that - a process that takes a programmer familiar with both VB6 and RB to do the conversion. In many cases it will be a line-by-line conversion even with tools to help.

Think about it this way: Some companies that convert VB6 to .NET are charging $1 per line of code. What are you paying for REAL's VBPC? Exactly. At least with VB Convert! you're funding a developer that actually cares and is willing to work with you.

In my opinion, RS should remove their converter application until (or if) they get it into a decent working state. Until then, give VB Convert! a shot knowing that you will spend some serious time converting a lot of things by hand. VB Convert! is a tool that can help save some time while VBPC is useless in its current state.