A Celebration of the Fastest Growing Companies in CT

This week the Connecticut Technology Council held one of my favorite events – the Marcum Tech Top 40 – celebrating the 40 fastest growing technology companies in Connecticut. It’s so much fun spending an evening meeting such successful people and reconnecting with old friends. We have been lucky to have the opportunity to work with many of the people in the room.

The diversity of the companies is amazing: from online travel service Priceline.com, to oil-drilling equipment manufacturer APS Technology, Inc, to vaccine maker Protein Sciences Corporation, to IT Services provider OpenSky, the overall winner with 18,221% growth!

One thing I can’t help but ask myself is: what makes some companies so successful while others struggle? Listening to the speeches of each category’s winner, there was one common answer – the team. I’ve always believed that a small, talented, focused team can accomplish amazing things, and these CEOs were saying the same thing.

Congratulations to this year’s Tech Top 40, and to all those who aspire to join them – my best advice – surround yourself with the best and brightest you can find.

Build or Buy? How to know if you need custom software

I met a woman yesterday who asked me if we could build some software for her business. I told her yes, we could, but it probably wouldn’t make sense. Let me explain.

Building custom software is an investment, and that investment usually doesn’t make sense unless you’re going to sell multiple copies of the software, or it’s going to give you a significant competitive advantage in your business. And I do mean significant.

For example, I spoke with a company not too long ago that was thinking about developing some software to help them with an internal business process. They had done their research, and there were packages on the market, but they didn’t exactly meet their needs. I spent enough time with them to give them a ball park quote, and it turns out the custom solution was seven times more expensive than the off-the-shelf solution. Frankly, this isn’t even a lot. Think about it – if the vender of the generic solution spent the same amount of money developing their solution, they would only need to sell seven copies to break even. I realize it’s more complicated than this, there’s distribution, support, marketing, overhead, etc. but what if they sold 70 copies? You can see how this kind of investment could pay off. And if they sold 700 – wow!

So this company decided to buy the off-the-shelf product that met most of their needs. In my opinion, that was the right decision. It only makes sense to build custom software for internal use when you can get a significant competitive advantage. Before you think about investing in custom software, look at what’s already on the market to meet your needs. It may not meet all of your needs, or meet them perfectly, but ask yourself how much would it be worth to have that perfect solution? Would I be willing to pay ten times the cost of this package? More? Often the answer will be no, and in that case, just find the product that meets your needs the best or allows you some ability to customize.

Want to develop a new product? Where do you start?

I’ve been working with a lot of companies lately that have never developed a new product from scratch. They all seem to have the same question – “Where do I start?”

The answer is always the same – with requirements, and by requirements I don’t mean a bullet list of features, although that’s a start. By requirements, I mean detailed requirements of what you want the product to do and how it should behave in every situation. Error conditions are one thing that’s typically forgotten. Requirements are also not necessarily functional, for example, the maximum (or target) manufacturing cost is a common, and commonly overlooked, requirement for an embedded system. They say the “devil’s in the details.” In this case, that’s true.

The first question clients have (well, maybe it’s not the first, but it’s the big one everyone wants to know) is “how much will this cost?” Without the kind of detailed requirements I’m talking about, it’s impossible to give any kind of meaningful estimate. That’s why we’ve had such great success creating an initial engagement that delivers requirements and a rough estimate of time and cost. This initial engagement typically lasts between a week and a month, depending on the scope and complexity of the project and gives the client accurate information that they can use to make decisions. We usually find areas of trade-off, like features that could be in a future release, and can balance the client’s time to market and budget needs.

So remember, next time you have a new product you’re developing. Details, details, details!

Training our future workforce

This week there was an article in the NY Times about Gadget Camp, a workshop for girls in River Grove, IL to expose girls to the skills needed to get jobs in manufacturing. I love this idea! As one of the few girls that took (and thoroughly enjoyed) wood shop and metal shop, I wish I had something like this growing up. There’s absolutely no reason girls and women can’t do these jobs.

Through my involvement with the New Haven Manufactures’ Association (NHMA) Workforce Development Committee, I’ve seen personally how many how many manufacturers there are in CT and how many jobs they have. Yes, there are jobs in manufacturing, and not only are there jobs, these are good jobs that don’t require a college degree. They do however require skills, especially math skills, and unfortunately, our public schools are not doing a great job providing them.

Our Vocational schools, however, are providing kids with the skills they need for these jobs as well as a good traditional education. Before getting involved with the NHMA, I didn’t realize that the kids at the Vo-Tech schools took the same academic course load as public schools PLUS training in their field. The kids that I’ve met are bright and passionate about their field. Whether they go on to college or not, they have a bright future ahead of them.

Programs like Gadget Camp and even more so, the Vo-Tech system, provide much need skills and opportunities for the kids that participate in them, and critical talent for our businesses. We should do anything we can to support them.

The Art of Requirements Writing

The one area where I see companies could improve and make a HUGE impact on their development is in Requirements Writing. Most companies err on the side of too little or, unfortunately, way to often, none.

The biggest problem we see as a result of insufficient requirements is almost always scope creep, meaning that because there is no baseline, features just keep getting added to a release, and the result often is that the release never gets released. The other common problem we see from non-existent or insufficient requirements is that what gets implemented is often not what was intended, and if by chance the implementation is done correctly, it has taken a lot more work, time, and interaction than it would have otherwise.

The other side of the coin is perhaps more interesting. It’s rare, but sometimes we see companies that put too much in their requirements. I think this fear is why some companies don’t do anything at all – they don’t want to spend eons writing reams of paper and analyzing every detail. Rightly so, it’s a waste of time. The kinds of things we see in this area fall into two main categories of content and formatting.

As far as content, the biggest error is trying to turn a Requirements spec into a Design spec, meaning that instead of detailing what needs to be done, the requirement details how it should be done. Now there is a place for this, but it’s not in requirements. Specifying the how in requirements really limits the options and almost always results in a sub-optimal design. If the requirements are being written by a business analyst, as good as they are, they are not usually experienced architects or developers. Even if they are being written by a developer, the benefit to separating what from how allows the developer to look at all the requirements as a whole and in a separate thought step design the how in the best way taking everything into account, not just one requirement.

As far as format, the least useful way to write requirements (and ironically, probably the most difficult way) is in paragraph or prose form. There’s just too much content, and the important points are not easily identified and digested. Additionally, it takes an additional step for every user of the requirements (development, QA, Tech writing) to get the relevant information out. Obviously Use Cases are a tried and true and very effective method, but even bullet points (as long as they contain enough information) are preferable. The information contained should include the user entries, the results, any exception or error conditions and any other affects of the feature, easily and quickly captured in a bullet point format without any extra text to wade through.

Bottom line – well written requirements are HUGELY helpful to everyone in the development process and will make a great impact on getting your product out quickly. I’m sure there are offenses I’ve missed here. What other kinds of things have people seen??

What it Takes to be a Successful Consultant

I have not written for a while on what it takes to be a successful consultant, but lately I’ve been noticing some common trends with our best people, and oddly enough it has absolutely nothing to do with their technical abilities. I’m really not sure what to call it – grace, poise, or just plain old fashioned professionalism.

In one instance, one of our clients handled an HR problem, let’s just say, in a less than optimal fashion. Our consultants there were affected by this decision, and one of them could have been justified to be hurt or angry, but to his credit, he just continued to do his job while the storm raged around him. He happened to be in our office one day while this was going on and his comment to me was “I have a job to do, and I’m going to focus on that and do my best.” Love that!!

In the second instance one of our consultants was working with an engineer at our client’s client on an integration project. I’ll spare you the gory details but this engineer was engaging in programming practices that would make any professional programmer shudder with disgust. The stories even made me shudder and I haven’t been a programmer in ages! To his credit, our guy worked thru the issues with this engineer without issue.

Although they’re all sharp, in fact some of the smartest people I know, I think I admire the restraint, respect and professionalism our consultants exhibit even more than their technical chops. We serve at the request of our clients, and being difficult or disrespectful does nothing for our relationships. I’m so proud to be a part of this team, with these amazing engineers and developers!

Girl Power! Encouraging News on Girls in Tech

I’ve written a lot on the alarming lack of interest of girls (and boys) in technology careers. This week I read some encouraging news I wanted to share.

Google’s inaugural science fair was held on Monday and the three winners were all girls! Google reviewed more than 7,500 entries to bring the 15 top applicants to Google headquarters for final judging. These 15 were interviewed by luminaries in technology, including a Nobel Laureate, National Geographic Explorers, and some of Google’s best and brightest.

As we know, there is no shortage of younger girls interested in math and science, but for some reason that drops off in middle school, yet these girls were all teenagers. Let’s hope their interest continues. We need smart people like this in technology!

Making the same mistakes

I hear it over and over again from technology execs – I know we should spend the time writing specs or working on our process or on architecture or designing a good UI or testing or documenting or - fill in the blank.

Yet, time and time again, I see companies making the same mistakes. It kills me! I asked myself “why do they do it?” After all, it’s so easy to improve your delivery time and quality a little bit at a time. I know it’s hard to find a place to start, but for some companies I see, anything would help them. When in doubt, remember that good requirements make everything else easier!

Then I remembered something I’ve heard repeatedly “The pain of the change must be less than the pain of the status quo”. I get that change is tough, but some of these changes (i.e. good requirements definition) are not that painful. I think a more accurate assessment would be “The fear of the unknown must be less than the pain of the status quo”

Do any of you have less than optimal practices in your product development? We all do, in one way or another. Things can always be better. Why do you stay where you are?

Innovation - Simple Is Best

As I recover from minor foot surgery I discovered an important fact. The use of crutches is exhausting. The only thing required of me to heal properly was not to put any weight on the foot. Sounds easy but after a few days I found the use of crutches to be limiting and exhausting. Facing six to eight weeks on crutches I began looking for alternatives.

A friend of mine recommended a Knee Walker. At first the scooter, as I prefer to call it, did seem laughable. But when I tried one I could see how such a simple device could be so helpful. After using one for the past 6 weeks I am a huge fan.

So what did I learn from this experience? Some of the most innovative products are the simplest. Entrepreneurs, inventors and engineers thinking of the next great breakthrough product need to ask themselves two simple questions.

What problem am I trying to solve?
What is the simplest way to solve it?

That is a good start for any new endeavor.

Driving Students to Tech Careers

I recently read an interesting interview with three senior executives at Google. The article was about women in technology, but one of their points intrigued me. They hypothesized that the prevalence of technology in our lives (smart phones, Facebook, etc.) will drive more young people to technology careers. They will use it and some will be curious about how you create a smart phone or an application like Facebook.

This sounds likely to me. Recently, I was speaking to a group of girls and shared that I had no idea what Engineering was when I went into college. All I knew was that it used math and science and I could get a good job when I was done. That was enough for me at the time. Fortunately, I enjoyed the intellectual challenge of solving problems and the satisfaction of creating something from scratch.

Now a days, when I describe what Advanced Decisions does, I have plenty of commonly known examples to point to. My typical “definition” of embedded systems programming is “writing software for an electronic device like your phone or your car, or your microwave, or medical equipment.” People usually understand that.

Do you think the prevalence of technology in our lives will generate interest in careers in tech? If not that, then what might? One of the points the women made in this article was that it’s not really about just women in tech. We have a shortage of programmers and engineers and need more regardless of gender.

Girls in Technology

A few weeks ago I spoke at Housatonic Community College’s Girls in Tech program. See this article in the CT Post for more.

Kudos to HCC for putting this on. It’s such an important issue. These were 7th and 8th grade girls, mostly from Bridgeport that had the opportunity to attend the expo and learn more about what kinds of careers are possible with a good solid STEM education. The possibilities excited them, and fortunately, this is the time to do something about it.

At this stage in their schooling they still have the opportunity to take advanced math and science classes and get the grades required to get into top schools and get scholarship money. This is the age where girls lose interest in math and science, but seeing what they can do with a strong STEM education, many of the girls were inspired.

Choices like nanotechnology and crime scene investigation are not obvious, but really inspired the girls. Many of them said they would devote themselves to their studies, with the goal of entering one of the intellectually stimulating and high paying careers presented at the Expo. I’d call that a success!

To the Cloud

The next big software war to be fought is in the cloud. I have been following Google Apps since its inception as an offshoot of gmail. Google’s ever improving suite of online software has evolved into Google Docs and for businesses, Google Apps. It is an economical choice for a small business to provide protected email, shared calendar, messaging, software applications and shared access to documents with NO I.T. responsibility.

Now there is a new kid in town, or soon to be. Microsoft is about to debut Office 365. It will compete directly with Google Apps for business and provide a hosted productivity and collaboration environment for businesses. Small businesses who typically cannot afford an I.T. staff or who do not want to maintain their servers will now have a choice.

Google and Microsoft are providing an integrated suite of common office applications PLUS a collaboration platform PLUS messaging. When offered at an affordable price it becomes very appealing. Especially when it does not involve those dreaded server updates and reboots. Let some one else worry about that.

So let’s see how this develops, there are many questions. Does our internet infrastructure provide the kind of responsive we have become accustomed to with our desktop/notebooks and local area networks? How many businesses are going to adopt Cloud computing and store important documentation somewhere out there? How safe, private is this data?

Many questions, the story is now unfolding.

A sad yet preventable story of software failure

I read an article today reporting that Nokia had announced that it was abandoning its development of its own Smartphone platforms and APIs. By itself, that’s not so sad. It’s smart to know when to cut your losses, right? The reason this story makes me sad, is that it was entirely preventable.
According to reports from insider Mark Wilcox, “there was no proper requirement spec for this new framework.” Aggghhhh! This makes me crazy every time I see it, and I see it a lot.
Companies think they can save time, or they don’t want to be “locked in” or say, “We’ll just tell the developers what to build.” In 20+ years of personal experience, I’ve never seen this work well. In the very best cases, tons of time is actually wasted by long meetings, miscommunications, and do-overs. Usually the end result is not really what the project sponsor wanted, but they settle. In the very worst cases, like this one, companies spend 2000+ man-years (yes, you read that right) developing something no one wants! In this case, they had two competing teams (I’ll have to address that in another post – just too much to say on that one!) and according to Wilcox "both teams had built the wrong thing.” Both teams! (This post may be my personal record in use of exclamation points.)
Another comment he makes is that “the engineers were incompetent. Now by that I don't mean that they're incompetent engineers – far from it. They were incompetent at designing APIs for 3rd party developers (a very specialist engineering skill) and they were incompetent at designing UIs (which most engineers are, myself included). Unfortunately they were doing both.” These could have been very bright engineers, but as Clint Eastwood said in one of my favorite Dirty Harry Movies, “A man’s got to know his limitations.” This also happens frequently and is an error made both by engineers (ego, desire to learn, fearing for their job security) and management (don’t want to hire specialists, over estimating their engineers). Again, in the best cases I’ve seen, the engineers can muddle thru and get something passable. On the other hand, it can be a train wreck as in this case.
The aspect that makes me the most upset about this story is the effect on all those engineers. They worked hard, I’m sure long hours at times, to develop basically, nothing. We engineers develop software and products because we take pride in our work and want to build things that people love to use and these engineers spent years not doing that. I can’t even imagine how unfulfilling that was.

Watson on Jeopardy

Did you see Watson, the IBM computer compete on Jeopardy last week. I did, in fact I was really looking forward to it. Obviously the geek in me was awed by the computing power.

Watson clearly dominated. In the three day match he beat the two human competitors by a margin of roughly 3 to 1. Obviously Watson got many answers right, but what I found interesting was what he got wrong. When he was wrong, he was VERY wrong! I’m sure we’ve all heard about the Final Jeopardy answer in the second match. All those people from Toronto never knew they were Americans! But some other more interesting mistakes where when he didn’t even give the right kind of reply.

For example, on the question: “In May 2010 5 Paintings worth $125 Million by Braque, Matisse & 3 others left Paris’ museum of this art period?” The answer was Modern Art, Watson said Picasso, obviously not an art period.

The use for this kind of computing power boggles my mind. We just have to remember to sanity check his answers!

Cloud Computing – Connecting People

I know of three different companies right now that are developing some sort of distributed applications, running on multiple computers and platforms. In many aspects these systems are wildly different. They’re being developed for consumers and businesses world wide. The platforms may be PC, Linux, proprietary hardware and/or mobile devices. The applications themselves, the complexity and the architectures, vary wildly, but the most interesting thing is the commonality.

All of these applications are about connecting people. Whether it’s a consumer focused social application or a global business application or a new distribution channel for an industry where distribution has been a huge issue, all three of these applications really are flatting the world and leveling the playing field.

It’s fascinating and gratifying to be playing a role in changing the way we interact and do business. It makes me wonder what I’ll be writing about changing ten years from now!

Software Process Improvement Consulting

In 2005, I joined Advanced Decisions to establish a Software Process Improvement practice within the company. Well, long story short, I got busy with our core business of software and hardware product development and we never formally developed that practice. The interesting thing is that we seem to provide consulting on Software Process and SDLC as part of many of our engagements anyway.

The most obvious example is our work with start-ups. We typically are engaged to develop their product, but often wind up developing their process, their team, and even on occasion aspects of their business. With our larger clients we develop good quality documentation that’s often used as an example of what to develop in the future. Even with our prospects, we ask them enough questions about how they are developing their products to get them thinking.

It just goes to show, the outcome of a goal or desire may not always look like you expect.