Opportunities for major improvements and advances

I was just thinking about software development over the years. I
don't know if I will be able to express these thoughts in 'text' but
I will try.

There are many many things that have to come together for
improvements in software development process.

These things (IMO) include:
a) the development environment, including the build system, the
language, etc.
b) the demand of the market, such as an almost insatiable appetite
for new software
c) Corporate Government, such as a rebalancing of power in a company
where the technical units are not dominated by the business units in
a fashion that constricts growth or stifles thought.

Imagine this:
You are on writing software for a machine that you can not have
access to but for 2 hours a day. You write your programs on cards.
Your turn comes and you hope your program "loads". In such an
environment you will not be apt to conceive the notion of continuous
builds. It is not an environment that is ready for such thought.

Imagine this:
You are writing software in C on a Unix machine in the early '80s.
Your salary is well above average. The machine you access through
your terminal is a major capital expenditure. Libraries and seperate
compilation units are available to you now. You have access to the
hardware all day, but your compiles take a long time because of the
time-sharing of the machine. You are thinking in terms of abstract
structures and you are aggregating fundamental types into domain
concepts. Memory is expensive. Disk space is expensive. You are
frustrated with the slow build times. You are frustrated with memory
management. You are frustrated with the debugger. There are so few
programmers that in order to utilize their skills more thoroughly
divisions appear such as Testing/QA and Product Management because
the developers are too expensive to use for other tasks. Because of
this the waterfall approach is used to serialize the tasks just as
developers would serialize tasks to be batched and ran on the
computers. Immediately it was recognized that feed-back loops and
recursion could help, and notice that both of these ideas are from
computer science (and electrical engineering).

Now imagine today:
We have desktop machines that are more powerful than the original
super computers. We can distribute programming easily. Threading is
easy. So, what can we focus on? Continuous build. Rapid feedback. We
can focus on improving the software process once again! What shows
up? XP, Crystal, Lean, etc. Were the ideas that form the basis of
thesse process had only by Beck or Cockburn? No, many many people
were having similar thoughts working through similar problems. I
don't want to diminish their contribution, because there were many
many people that were happy with the state of software development as
well. We can see the division even today.

Now imagine tomorrow:
What I have been describing is "overcoming constraints". When
development is not the bottleneck who is? What changes are going to
happen? After these constraints are removed it will eventually fall
back on development and when it does what will be the focus for
improvement?