Readily available frameworks and APIs can make developers very productive. However, they can also limit developers' imagination, explains Overstock.com principal software engineer Chris Maki in this brief audio interview with Artima:

http://www.artima.com/lejava/articles/javaone_2007_chris_maki.html

To what extent do you think there is a role for the in-the-trenches enterprise developer to devise innovative and out-of-the-box solutions? In your projects, how do you mitigate the need for productivity that comes from following the prescriptions of a high-level framework, and the desire to come up with original and sometimes surprising, solutions?

The largest expense companies face in their software development is programmer imagination. All one needs to do is read www.worsethanfailure.com. Craig Larman makes a similar point in his book Applying UML and Patterns in which he discusses the need to limit developer imagination because it is so costly. What customer in their right mind would want to pay for proprietary software when open source works?

I've seen quite a few internally developed frameworks. All exhibited poor design, high cost to use and high maintenance costs. Developers should focus on learning how to use Spring, Hibernate, Velocity, Struts2 etc before they reinvent the wheel. Simultaneously, deverlopers hould learn OO as well. I find most Java developers, even some "experts", don't know OO.

Conversely, every developer who I've admired has managed to perform superbly simply by knowing the open source frameworks and using them to their advantage. What framework do the authors propose? Rails, only better? Hibernate, only better? Better frameworks are being created every day, i.e., the next version of Hibernate, the next version of Spring. Imaginative developers can certainly find a place contributing to open source development.

I have to say I'm a little puzzled by this. Yes APIs can be limiting. I've had the experience of trying to use an API and have it defeat me. But I've also had the experience of an API allowing me to do things that I would never have the time to achieve from scratch.

For example, I'm currently working on embedding multiple concurrent views of a 3D environment into a Java Swing app. I would never have attempted with without APIs that give me the tools I need to create this with a few hundred lines of Java.

I think sometimes software engineers get a little caught up in this completely false notion that the closer you are to the hardware, the more talent you must have. I've seen this attitude before where people imply that because they work on a Java compiler, they must, therefore must know more about developing code in Java than an engineer who 'just' uses Java.

Yes, APIs and/or frameworks can put you on rails but sometimes that's the best solution. I don't particularly want to work on certain types of problems for the rest of eternity. A lot of what some frameworks do are not interesting problems to me. They are often not really very challenging or complex.

You should really provide a transcript of this interview. I'm not going to listen to an audio recording of something "short" if I can read it in 1/10 of the time.

> You should really provide a transcript of this interview.
> I'm not going to listen to an audio recording of something
> "short" if I can read it in 1/10 of the time.

The description tells you all there is to know about the interview. There's nothing more to be learned from listening to it.

obviously, yes. irrelevantly, yes.

You are given 100 lbs of clay. Make of it what you will.
You are given 10 bricks. Make of it what you will.

You can more things with the clay than the bricks; but you may not need to.

Real java/C/C++/BAL programmers write in the native syntax of their languages. Framework programmers write in the syntax enforced by the framework maker.

Back in 1999, I began writing servlets: System.out.println(). That's how it was done; Jason Hunter's book still shows you how to do that. No one does anymore. JSP was the first (official, anyway) framework for servlets. Which has been wrapped by a number of others.

Basic assemblers gave way to macro assemblers (less so on the mainframe), and so on.

All of which supports the notion that if you find yourself generating code, you've got the wrong language.

Programming these days is all about utilising and taking advantage of existing frameworks and API's. This has become a common practice and has proven very productive.

I think that frameworks more than API's limit developer's imaginations because they provide general solutions to specific problems that would otherwise need to be solved. Imagination and creativity can suddenly become redundant when there is nothing there to solve.

Core language API's on the other hand provide a limited means of solving problems that requires raw programming. This promotes imagination, creativity, and learning - but not without the expense of developer productivity and risks of code instability. I think there is a role for this kind of programming to the extent where the innovation is simple and specific and not complex and general.

I recently posted a similar view here:
http://warpedjavaguy.com/2007/08/08/elementary-java-solutions/

Frameworks and APIs don't so much limit peoples' imagination (at least overall, maybe it is true for some people) as empower those who lack the skills or drive to get down to the wire to use a language/platform/whatever that they'd otherwise be unable to.

Taking it to the extreme the operating system you're using is a collection of frameworks and APIs.
If you want to do without you're free to start poking individual bits and bytes into your CPU.
But I seriously doubt that would lead to you gaining any imagination (unless it led to the imagination that there must be a better way, let's create an operating system that we can talk to through a programming language that allows us to use more or less human readable commands).

And given the flood of APIs and frameworks being released all the time it seems to me that there's more imagination than ever (or maybe more of a drive to "make a name" by releasing yet another web application framework to rule all others).

What frameworks and APIs do for me, and no doubt many others, is enable us to imagine higher order problems, problems we'd never get down to solving without those frameworks and APIs because all our time would be spent reinventing the wheel constantly (and most likely implementing our own frameworks and APIs in the process).

Dull work limits developers' imaginations. Solving the same problems over and over again dulls developers' imaginations. Frameworks and API's are nothing more than tools. A hallmark of a professional versus hobbyist developer is finding a tool to suit the problem and when one isn't available create one. If Struts/Hibernate/Spring/Rails/??? solve a particular problem required by the organization, it's incumbent upon the developer to use it.

It's not the tools dulling our minds, it's the problems we're solving.

"The enemy of art is the absence of limitations."

George Orson Welles

That fact, however, is no excuse for Struts.

I think Chris Maki makes an interesting point, though I think some folks may have missed the premise. Chris starts out by contrasting his experiences as a Java developer with an earlier set of experiences on the NeXT platform (which as he points out is now -- in essence, at least -- Mac OS X). Reading between the lines, it was the NeXT platform that made the developers he worked with feel they could accomplish anything they could think of because of its rich, elegant, and powerful frameworks, not in spite of them. I don't think he was arguing against frameworks at all.

Rather, I think he was contrasting that environment with the current Java ecosystem, which features a multiplicity of frameworks that tend to be strongly prescriptive and far less flexible, channeling developers' efforts into narrow paths, and thus limiting their creativity. I've had the same experience myself, and it's been a painful thing to witness the stultifying effect this approach appears to have had on many developers.

The worst outcome of this, in my opinion, is an astonishing lack of interest in design. I'm not talking about Big Upfront Design so much as iterative design of classes, components, and layers. Most of the so-called 'architects' I've met on Java projects seem to think their job begins and ends at framework and tool selection -- they seem to think that all that's left from that point on is cookie-cutter coding that requires little to no thought.

Worse, I've worked with teams of Java developers who would rather go for root canals than have a 15 minute whiteboard session on the design of the stuff they're about to code. And I've also witnessed the resulting train wreck. Ouch!

> "The enemy of art is the absence of limitations."
>
> George Orson Welles

That's way true but where should limitations be in our field?
Should thy be set by the product owner, the users etc. or by the APIs?

Agreed, some Java APIs are ingenious while lots of them are extremely poor (especially those around J2EE).
The trick is to prevent the bad ones from dragging you down to poor design or low moral and/or productivity.

It's OO that let's you shield the bad one's away and let's the good one florish!

high level developers should be working closely with business owners to design the imaginative cases. apis and framework serve an important in delivering the common expectation, but every once in a while, a need arises that builds upon or challenges those expectations. how else can you make an ipod? to give up on that close communication, and i really mean direct communication because thats when the sparks fly, is really to shoot the company in the foot.

in direct answer to the thread title, no, they do not, and should not. imagination can't be held back by a tool. unfortunately imagination is all too rare in technology because it is still seen as a profesion to pursue when you aren't creative.