Tag Archives: mistakes in software

The Top 5 Rookie Mistakes in Software – #3 Techno Hype

technology.jpg

The Technology Dream

It’s just a tool, not a Strategy

It’s amazing how often technology gets confused and spun as a marketable feature. It’s not uncommon for companies and governments, for instance, to state that they will “Leverage Technology” as a business strategy. In the same breath, they’re also going to reduce unemployment, clean up the environment and fix the economy. Sure they will.

There’s an exciting appeal to ‘technology’.  There’s still a mystery and newness to even the word that elicits a dreamy promise of endless possibility.  It’s impressive apps like Google Earth, Halo 3 or the iPhone that people likely think of when talking about technology; apps that look good, sell well, and entice people to get lost and obsessed in them.

Sexy apps, however, are built by clever people with a focused vision around capability, content and a dreamy interface. The fact that they leverage technology is almost incidental. It’s easy to get caught up in the excitment of the dream and forget that business is still business regardless of the tool you use.  The truth is, it’s not uncommon for both business people and technical people to miss the point that technology is only a tool. Without a purpose, that tool is just a means to an undefined end.

Without establishing a direction and purpose for a software product that is focused on boring old things like: User, Market and your Business; your technology dream will simply deflate into another expensive mistake rather than a hot app.

The Framework Dilemma

As technology professionals, we get caught up in the dream too.  I’ve been guilty many times of approaching business problems with a technical solution without stepping back and wondering if it’s truly the right thing to do. It’s easy to get wrapped-up in the world you know and use that as the solution to all problems. “Have you considered building an Application Integration Framework?” – Those were my words. It seemed like a reasonable thing to suggest. This guy’s media company had multiple products that couldn’t talk to each other and ‘Integration’ was high on his agenda.

“NO! NO FRAMEWORKS!” – Was his response.  He even stood up out of his chair and leaned forward towards me pretty aggressively when he said it.

Wo, that guy was jaded. But I understand why now.  He quickly calmed himself and explained to me that a consulting company had sold him the same line a couple years ago. They spent those 2 years in, what I call, “a Dark Place”, just building a Framework. They didn’t consult with them about what the products do, or what the user needs, or business drivers, or the data or how this could tie into their overall technical strategy – nothing like that. They just built a framework.  It took 2 years of nothing tangible, but these consultants were finally kicked off the property. All there was to show for the $1.2 million spent was a bunch of code that had no business value.  I’m sure it was a brilliantly designed framework, but it didn’t do anything. I’m also sure there are thousands of skillfully composed frameworks out there sitting lonely on subversion servers around the world. I’ve personally participated in a framework or two that went nowhere. It’s a common thing for developers to want to do.

targeted.jpg

I don’t want to dismiss the importance of a proper architecture and framework; all software applications need a solid foundation. But they have to be built to fit the business need, and with a specific user-driven purpose.  Frameworks should be small, lightweight and grow with the product. Key to making sure that happens is: every aspect of a framework has to have a consumer. If someone on your team is building a component or framework or utility in anticipation of the potential of it being useful, that effort should be denied.

Technology For Technology Sake

My old boss used to have this tendency to wander into my office and recount stories about his past. He didn’t have all that much material, so his stories got repeated a fair bit – I didn’t have the heart to tell him that of course.  Anyway, one of his more riveting stories I got to know well, was about the specifics of a product idea of his that failed. It was essentially like this: a data service architecture that could connect to multiple databases; a domain layer that sat on top of that which reconciled data from these different locations; on top of that was a communication layer based on web services and finally there was a forms builder to create custom interfaces as the top layer of the product.  He thought it was such a great idea and would shake his head in bewilderment as to why it never went anywhere. “Well, what did it do?” I asked him one brave day. “It could connect to multiple databases.” Was his answer.

“To do what though?” I asked.

“Well, to do anything.” He said.

“Anything that needs multiple databases…” I said, to be agreeable; but really I just wanted to get out of the conversation.

So, who’s going to buy that? It’s a thing that doesn’t have any real purpose, except to say it serves a purpose behind an unknown purpose. A body without a head. I didn’t have the heart to tell him, of course, because he thought it was so awesome … and it was kind of his baby. But like a lot of people, he chose to build technology for technology sake, and didn’t appear to understand that that isn’t a product or strategy, it’s only a tool.

Chris Ronak

Advertisements

The Top 5 Rookie Mistakes In Software – Intro

Introduction

It’s pretty easy to throw some software together.  Almost anyone can do it.  Simple tools, Drag&Drop screen designers, sample databases, etc. make creating a software app just a few mouse clicks away.

I used to work with a sales guy whose family owned a sheep farm that he helped out with on occasion.  After getting a bit frustrated with how disorganized his family was about managing their sheep, he decided to do something about it.  So after reading a couple blogs, he bought a “For Dummies” book and taught himself VB.  He hooked it up to an Access database and in a few weekends he had built a sheep-tracking system.  Bam, just like that.  Easy.  Even a sales guy with a mere hint of technical aptitude can write software.

As it turns out, lots of non–technical people dive into the software game.   After all, how hard could it be?Small team of developers If you can’t do it yourself, you just hire some developers, tell them what to do, and they make it work.  Easy.

It’s interesting in a way, that there are so few barriers inhibiting inexperienced people from launching a software initiative.   In their mind, it’s just a few screens, buttons & graphics – it just doesn’t look that complicated.  Even if it’s a highly-integrated enterprise system that is connecting multiple disparate systems, performing complex business queries & algorithms and accessed by thousands of concurrent users – it’s still, at the end of the day, just a few screens & buttons.  Because that’s all they see.

The odd thing is, those same individuals wouldn’t dare dive into leading-up the design & construction of a 90-storey high-rise building without experience.   It’s clear why: a high-rise is more visual, physical and the obvious immensity of it is intimidating. They know you can’t just go hire a bunch of cement workers, plumbers & electricians to “Go build me a High-Rise!”  But somehow this happens all the time in software.   Curious, isn’t it?

So, to start a discussion around this pervasive problem, I thought I’d put together my Top 5 Rookie Mistakes that both inexperienced and experienced people make in software.  There are a lot more than 5, but I thought I’d try to stop there.

I have to caveat the perspective a bit.  There are many rookie mistakes made in an organization that don’t have a direct relation to the software/technology areas (marketing, sales, business development, finance, operations, etc.).  I’ll leave discussions around those to the experts.  I also refer a lot to product and market.  Regardless whether the software is to be delivered as an internal or commercial product, these rules are the same.

Learning to DanceAlso, there’s nothing wrong with being a rookie or the new guy.  The rookie is usually the person with the most energy and enthusiasm for an initiative; and is driven by a vision.  He/she isn’t jaded by mistakes & failure and can often become the true source of life for a project.  The intent here is to help to avoid common mistakes and pitfalls of that role; not to criticize the rookie.

So, here goes.  The Top 5 Rookie Mistakes in Software.  I’ll stagger them out over the next few days. This is, after all, an agile effort.

Chris Ronak