Fog Creek Software
Discussion Board




Innovation, Productivity, and Abstraction

How are Abstraction, Innovation, Productivity and Functionality related?  (Couldn't fit functionality in topic line.)

Abstraction yields greater Productivity at a cost of Functionality and Innovation.

Innovation requires greater Functionality at the cost of Abstraction and Productivity.

How would you relate these terms?

I think the Win32 API inspires innovation and gives greater functionality at the cost of abstraction whereas the .NET environment has abstractions that give greater productivity at a cost of functionality->  (Having to declare API calls and not having the exact same functionality as the Win32 API available natively in .NET.)

The Rock
Wednesday, June 23, 2004

> How are Abstraction, Innovation, Productivity and
> Functionality related?

Ooh, ooh, I know. They are all key words in buzzword bingo. Do I get the prize?

old_timer
Wednesday, June 23, 2004

you needed to cross-actualize the bingo matrix paradigm.  THEN you get a prize.

EAW
Wednesday, June 23, 2004

I'm trying to be serious here guys.

The Rock
Wednesday, June 23, 2004

They are all words you'd see in a Microsoft press release and/or white paper.

Mike
Wednesday, June 23, 2004

"technology"

hoser
Wednesday, June 23, 2004

This reminds me of Macroeconomics 101 -- what's the relationship between capital, interest rates, profits and taxes, taken in pairs?

Economics is called "the dismal science" for a good reason, but compared to what you're doing, it's nuclear physics! :-)

Does abstraction impede productivity?  Sometimes.  Sometimes abstraction improves productivity.  How's that?  Because you can only talk about productivity in the context of what work is being produced.

Let's make this more concrete.  Lots of people, myself included, have pointed out that the file IO classes in the .NET Framework are very abstract.  FileReader, StreamReader, Stream, FileStream, all the TextEncoding streams, blah blah blah, who understands all this stuff?

The thing is this: if what you need to do is get all the bits of a known file in a known format from a known disk location and into an array, the much lower abstraction in perl is way more productive.

If you have my job though, it's certainly not.  I have a bunch of code which needs to talk to a file, but the "file" might be in any of several character encodings,  might be on disk, in memory, in memory in another process, in a database... and in the future we might have to support various encryption standards as well. 

The fact that I can write the core functionality code to talk to a Stream object with an Encoding object, and then write support code around it to wrangle the zillion specific cases into the appropriate Stream and Encoding subclasses, is a HUGE productivity win because I don't have to write the same code a zillion times.

Eric Lippert
Wednesday, June 23, 2004

Thanks for the reply Eric.  That's the kind of response I'm looking for.

Now would you say that you can be just as innovative with all those layers of abstraction?  After all you have lost some functionality haven't you?

The Rock
Wednesday, June 23, 2004

Relations of Abstraction, Innovation, Productivity and Functionality.

Functionality is the base concept here.  Your solution needs to produce a certain amount of functionality, arranged in some way to reduce presentation complexity to the user.  Typically measured in requirements, additional measures can be function points or Scenario steps.

You also want to partition the functionality across the modules or objects of your solution, to minimize modification 'ripple effects'.  This partitioning allows you to partition the work that produces the modules/objects.

To reduce the complexity of the solution, you want to arrange the paritioning into a hierarchy of modules/objects. 

Abstraction lets you do this.  But you need good criteria to use.  What is 'good' criteria for Abstraction levels, partitioning, object definition is a subject for another thread. 

Productivity:  You want to produce this functionality in a cost-effective way, with predictable schedule.

Innovation:  You want to balance 'clever hacks' with re-use of existing stuff known to work.

So: Functionality defines the size and complexity of the solution.  Hierarchy (with Abstraction) allows you to manage the complexity of the solution.  Productivity must be balanced with Innovation during implementation.  Too much Innovation leads to systems which never get finished.  Too little Innovation leads to 'clunky' systems which reproduce the mistakes of the past.

AllanL5
Wednesday, June 23, 2004

Wow! Great answer AllanL5.  I never thought of it in an end user or per-solution way.

I'm thinking along the lines of API's and Joel's article but my train of thought may be wrong and too narrow.

The Rock
Wednesday, June 23, 2004

I wish i could have said what AllanL5 said.

son of parnas
Wednesday, June 23, 2004

I third that. Great answer Allan*

Mr. Analogy
Wednesday, June 23, 2004

Abstraction provides greater long-term productivity at a cost of short-term productivity. It doesn't affect functionality/innovation, because functional requirements come first.

Nearly Nameless
Wednesday, June 23, 2004

In my experience, abstraction may lead to reduced functionality, especially usability, when the abstraction is a huge productivity boost for most of the system but stands in the way of the most appropriate solution in a few areas. Of course, budget permitting, that could be helped.

Which is why, I take it, MS designed ASP.NET with the credo of "no black boxes" - everything can be worked around at a cost of gradually increasing complexity and loss of productivity.

Peter Arrenbrecht
Thursday, June 24, 2004

I'm going to have to, aaah, go ahead and disagree with you there, Bob.

Programming *is* building abstractions.  Wrapping the bits on a disk in a read() function, and wrapping read() calls with icons and scrollbars -- they seem to differ only by degree.  You're constructing a new concept or data structure or what-have-you, but most of your work is usually going to be putting an abstraction around it that makes it palatable to people who aren't CS PhDs.

(Ok, some programs aren't really abstractions.  Dijkstra's algorithm by itself isn't really an abstraction -- it's creating some new data from some old data.  But everybody knows it now, so it's just another level of abstraction you use to create your abstractions.  And the vast majority of programs use no complex algorithms at all -- how many programs are you running right now that need something more complex than Dijkstra?)

disagreeable fellow
Saturday, June 26, 2004

*  Recent Topics

*  Fog Creek Home