In several earlier posts, I have written about how I think
it’s time for software developers to stop thinking so much about the technology
they use and start focusing on the business problems they solve. There are two primary reasons for this:
- Writing maintainable software isn’t easy, but it’s getting easier every day. Integrated Development Environments, such as Visual Studio or Eclipse, give developers the tools they need to write, refactor, and debug software at their fingertips. Modern programming languages give developers needed functionality out-of-the-box, while abstracting some of the lower-level concepts, to help developers be more productive than ever before. Finally, and perhaps more importantly, with the thousands of technical bloggers and bulletin boards out there, it’s easier than ever to find answers to your questions using your favorite search engine.
- The average technologist doesn’t know about the inner workings of a business process, nor do they seem to care. "Tell me what to build and I’ll build it" is an attitude that’s all too common among technologists today. On the flip side, too many business people know little to nothing about the technology that they’re using and managing. Their attitude seems to be "that's a technology issue, so the technology people should deal with it". Someone needs to bridge the gap in order to create solutions that bring out the best of both worlds.
Business analysts are supposed to fill this gap, but too
many times true business analysts are simply not present, or not focused on
what truly makes a project a success. I've heard about some cases where business
analysts function as middle-men that just get in the way, because they don’t
know enough about either the business
or the technology. Project managers should be able to fill this
gap too, if they are to truly have the knowledge necessary to be the ones primarily responsible for delivering a product. Time and budget constraints get in the way,
though.
Should it fall on either the developer or software architect
to fill the gap? I used to think so, but
I used to work in a consulting company where the developer worked directly with
the client, with no business analysts or project managers to step in and help. In that particular case, it absolutely makes
sense for all of the developers to go take a business class or three and be
versed in both business and technology.
But what about situations where business analysts and
project managers are present? As much as
development is getting easier, it’s still hard.
It took me four years of study and experience before I felt like I knew
enough to be fully comfortable as a technologist, so I started branching out by
getting an MBA. But I know full well
that I don’t have the knowledge to create a site with the scalability needs of
Google, or the perfection needs of a pacemaker.
The need for programmers to know other items not directly related to a
particular technology is high as well, such as software readability, predicting
scalability, etc.
I think the answer is that the hard-core technologist isn’t
going away, despite the rise of business/technology hybrids. Instead, I see software teams made up of a
mix of strong technologists and adequate technologists with a strong business
background. It would help greatly if we
could also have all people in the development process gain more specific
technology and implementation knowledge.
This is not a small task, but a necessary one if we are going to enable
our technology to meet business needs more easily.
No comments:
Post a Comment