Fog Creek Software
Discussion Board




Writing code is dead

It seems to me that the practice of writing source code is rapidly dying out. Instead, we are shifting to desigining objects & behaviours in a more abstract way and letting IDEs, scripts, frameworks and so on do the plumbing & wiring.

In future, the skillset for a developer will change to include even more abstract thinking, selecting types & patterns of behaviour and creating the pipeline from those abstract definitions to the generators which create the working system.

Opinions ?

WoodenTongue
Friday, June 18, 2004

Read Microsofties and his fictional product of graphical coding treating objects like Lego (TM).

Actually, I look forward to programming using proteins, the interface almost molecular and the viruses we could have...

Simon Lucy
Friday, June 18, 2004

In your dreams, laddie.

Sorry, feeling a bit Druss this morning ;)

Len Holgate
Friday, June 18, 2004

Just a couple of thoughts...

1. Support will still have to be provided by someone who understands exactly what the hell is going on under all the framework abstraction.

2. The "pipeline creation" process better be flexible enough to provide for business change.

IMHO, #2 is the main reason why it didn't happen yet, and why I'm *very* skeptical about it ever happening at all.

Paulo Caetano
Friday, June 18, 2004

"In future, the skillset for a developer will change to include even more abstract thinking, selecting types & patterns of behaviour and creating the pipeline from those abstract definitions to the generators which create the working system. "

This is true only if your tools are actually able to understand the bussiness problem that needs to be solved in enough detail to make automatic code creation possible. Programming is being done on lots of different level. If you write a complicated piece of XSL to transfrom XML document A into XML document B you're still programming, IMHO.

Lots of processes can be viewed as a chain of one or more transformations. The idea of a pipeline is already implemented a number of times (BizTalk, Cocoon, Java filter/servlet chaining). It is not hard to get your hands on a framework that handles the flow of information from one processing node to another. The actual work goes into describing the kind of transformation that must be done.

Since systems integration can involve wildly different systems with datamodels that come from opposite parts of the universe, transformations can be complex. There is no artificial intellig3ence that just extracts the transformation rules from one data model to the other. This transformation has to be written down in some kind of formal description (XSL, VB code, DDL,....). Creating this description is 2what a lot of programming is all about.

Say cheese
Friday, June 18, 2004

WoodenTongue,


Go read Joel's Article on "Leaky Abstractions" and then let's continue this discussion.


I have found it to be dead on and have not been able to refute it yet.  Therefore, I accept it as an accurate representation of the current situation within the development world.

KC
Friday, June 18, 2004

WoodenTongue,

I understand your point, but only if we think about business applications... Higher abstract levels in these contexts mean understanding needs of users and being able to replicate social interactions at work.

But what about the developers who build the "abstract definitions"? "types & patterns of behaviour".

are you talking about components?

Cecilia Loureiro
Friday, June 18, 2004

KC wrote:
"I have found it [Joels' article on Leaky Abstractions] to be dead on and have not been able to refute it yet.  Therefore, I accept it as an accurate representation of the current situation within the development world. "

So, KC, are you saying the Joel's analogy describing leaky Abstractions is accurate?

So, Joel's abstraction on Leaky Abstractions is, itself, the one exception to his rul that Abstractions are always Leaky <g>

Mr. Analogy
Friday, June 18, 2004

We heard all this in the 80s with so-called 4GLs.
Fizzle.

We heard similar strains in the 90s with things like PowerBuilder.
Fizzle.

Software ICs.  Component Assembly.  Executable UML.
Sigh.

Somebody's always prattling on about the end of programming -- an eternal search for the Fountain of Sloth.  And yet nothing ever comes of it.

Something just occurred to me...  Programmers might be like real estate agents in a way. 

Are real estate agents needed?  We could all just upload our home specs and pricing to a single listing service where buyers could find their dream homes and nobody pays any commission.  It's not like the technology is beyond reach.  And yet, discounting the occasional FSBO, most of us still pay huge agent commissions.  Why?  Because without the agent's subtle badgering and cajoling and oversight of the details, hardly any sales would ever complete.

Likewise, without programmers driving a project toward delivery and demanding minute details and decisions, all the teary-eyed utopian visions of the business folk might wallow in an eternal dream state.

Or perhaps I had merely spent far too much time at over-funded dot-bombs and in IT department purgatories.

Cabby
Friday, June 18, 2004

KC wrote - "Go read Joel's Article on "Leaky Abstractions" and then let's continue this discussion."

I already did. Pray continue  . . .

Cabby wrote

"We heard all this in the 80s with so-called 4GLs.
Fizzle."


In the 80s I used a text editor and command line compiler in DOS. Now I use complex IDEs and code generators. I can manipulate forms without having to compile the whole thing every time I move a pixel. We don't call it 4GL but . . .

The point wasn't that programming will come to an end, but the skills that are needed are fundamentally shifting. It will keep the same name because, like the boiled frog, change happens too gradually to trigger a response.

WoodenTongue
Friday, June 18, 2004



If every piece fits exactly with your requirements every time, then yes, you may be correct.

In reality, I have yet to see this.  I know of many business operations/functions that various tools fit 80% of the requirements, but they don't fit everything.

Therefore, you have to customize the tools or build other tools to complement what you already have.

If we can build all-encompassing models (object, frameworks, etc) that can be used for lots of stuff and simultaneously fit *my* exact requirements, then it *might* turn out as your describe.

KC
Friday, June 18, 2004

Cabby makes good points... the devil's in the details.

Rick
Friday, June 18, 2004

I'm going to go with finite automata theory on this one.
If we can't even design a tool to tell if you program will terminate properly, how in the heck can you design a tool to write error free software that does any abstract task you can think of? That'd be great, just write one killer app mondo 9GL language thing with drag and drop that any Corporate VP could use to write software and then all the real programmers can go work at McDonalds where they belong. Yeah, right!

Andy in Austin
Friday, June 18, 2004

>like the boiled frog, change happens too gradually
>to trigger a response

The frog thing is an urban legend (I know it's tangential, I don't mean it as a criticism of your point).


Friday, June 18, 2004

A picture is not always worth a thousand words.

The diagram equivalent of thousands of lines of source code is going to get real ugly, real fast.  For snapshots of particular structures and abstractions, it's great.  To replace source code altogether, a nightmare.

Jim Rankin
Friday, June 18, 2004


If coding were dying out, and automation and abstraction obviated it, we wouldn't be sending development offshore.

The reason the work is sent offshore is that it's a way to save money on development. The reason companies have to take the drastic step of using workers on the other side of the planet to save money is that automation, 4GLs, CASE tools, and other silver bullets haven't worked as well as management was promised.

Software development remains labor-intensive, and thus expensive. So, to save money, companies are using cheaper workers.

If technological improvements allowed 5 semi-technical guys in Manhattan to do the work of a 20 PhD Bangalore development team, without the hassles of distance, businesses wouldn't bother with Bangalore.

Jon Hendry
Friday, June 18, 2004

The graphical schematics are more cumbersome to work with than textual descriptions: they take more space and growing connections become very confusing at alarming speed. For the time being, text has the most expressive power.

Ever tried to use one of those experimental graphical languages that the CS Ph.D.'s are so fond of concocting? They look very cute and easy, as long as you don't attempt to do anything more complex than a single "if-then-else".

No C
Saturday, June 19, 2004

Let's face it: if programming was easy, accountants would be doing it all with Excel macros. But that's not the case, and we all know why.


Saturday, June 19, 2004

They've been saying this since the 80's
When the "object revolution" started.
Internet sure has enabled code reuse,
but not on the seamless level they prognosticated.
(as usual)

In my experience. even reusing objects locally, across a firm, was a major effort in documentation, and only don't on a trivial level.  A few generic DB objects, or some calendar stuff.,

Bella
Saturday, June 19, 2004


Programming is not dead, it has evolve since machine language programming.

API's & Framework are handy so you can focus
your time designing the nicest solution instead of re-inventing the wheel coding the "pain in the ass" routines
like Zipping a file, sortings datas,etc...,etc....

Bobba Feet
Sunday, June 20, 2004

The thing I've found about all the high-level design Silver Bullets is that they are great at doing things which are purely automated code generation with totally pre-specified behaviour.

For example, the JBuilder designer is great at building a very complex GUI page with lots of edit fields for parameter entry, layout, buttons in all the right places etc etc. It can also be used to attach listeners to my controls, and in future such tools may automate away a lot of fairly standard kind of work that fits in well with established design patterns.

But one thing it can never, ever do, is "know" the business logic of my program. What exactly do I do to validate the entered parameters against each other and against the current state of the system? I have all these numbers, but the specific thing that needs to be done to them has never been done before. It's not like I'm doing routine stuff like putting them into an array and writing them out to a ZIP file, I'm actually validating them against each other and using them in an ultra-specialised kind of way, perhaps via complex algorithms that I had to come up with for this specific purpose.

I find that 90% of programming that has to be done by hand falls into this "business logic" category, where "business logic" means any specific behaviour required in your specific application, other than the GUI, frameworks and platform-related stuff that drives it.

This kind of thing could only possibly be automated away by Humanoid AI, so in a word, I don't think we will ever see such tools developed by Computer Science as we know it.

In fact, I actually believe that the automation of programming has plateaued out and will not get THAT much more sophisticated than it currently is. Maybe tools will come along that'll be better and more efficient at automating away the routine stuff, but it will still at most be able to generate stub routines for any application-specific Business Logic.

Adrian Planinc
Monday, June 21, 2004

*  Recent Topics

*  Fog Creek Home