Grady Booch: The issues vexing developers
Summary: Veteran programmer and IBM Research software engineering chief scientist Grady Booch discusses the biggest areas of growth and concern facing developers today
...raising levels of abstraction and we see that in our middleware, in our language and in our processes.
While there are some fascinating languages being proposed, the problem is turning those niche ideas into mainstream is very, very hard because it's not just the best technical idea that wins.
So, if you were just getting started in the industry now, what would concern you most?
It's hard to generalise but there are a handful of things that would be keeping me awake. One of those is the problem of coding for multicore processors. In many domains the presence of multicore is going to be invisible to the developer, as it should be because it is a layer of abstraction below it.
Another issue is the cacophony, or should I say cornucopia, of choices that a developer has.
What Apple has done with Grand Central Dispatch, what Intel is doing with its pattern languages, and what IBM is trying to do with the X10 programming language are all examples of masking the inherent parallelism from the average developer, and that's as it should be.
There are some domains for which the developer must get deep into knowing that there are multiple cores and exploiting them but that's a relatively small segment of the marketplace. But for that segment it's a really hard problem because we don't know how to solve it. Dealing with intimately concurrent systems is wickedly hard.
Another issue is the cacophony, or should I say cornucopia, of choices that a developer has. What scripting language do I use? If I'm doing a web-centric thing, what framework do I use? Is it Drupal, or is it whatever, or do I just hard-code it myself? There are millions of choices. It becomes a challenge for someone to say, "I'm going to choose this particular platform", and then move on. But the problem is the world changes out from under them.
There was a Google employee — and I'm not saying disparaging things about anybody — who was complaining, saying, "Look at Google's code base. Many pieces of it are 10 years old and it's positively old and cranky."
It's really fun and interesting working in a new area. Multicore and all these different platforms are new development problems, but what we've not touched on are legacy problems. Google has a legacy problem, Facebook has a legacy problem. The moment you write a line of code, it becomes legacy. So it's not just a problem of old enterprises, it's a problem even for newcomers.
So what can enterprises do to help alleviate this problem?
There are things that help. One of those is the process of continuous refactoring, which is to keep those legacy systems alive means you have to apply some energy to them but for cost-saving reasons many organisations choose not to do so.
They patch and patch and patch until it falls apart due to its own sheer weight or, more likely, some leaner competitor comes along who has no legacy constraints and blows them away in the marketplace. That's the way the market works.
Get the latest technology news and analysis, blogs and reviews delivered directly to your inbox with ZDNet UK's newsletters.
Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.
Talkback