The 21st century is upon us and we have largely failed at creating a complete methodology whereby collaborative software development efforts achieve the types of productivity that a lone effort, or a very small team effort can achieve. This is not to say that all teams have failed to achieve productivity, but that assembling a team that will be productive is hit-or-miss. The reason is that productivity is not implicitly designed into the development platform. What I mean by this is that we have inherent problems both in infrastructure and in language (some more so than others).
On the infrastructure side, the success of HTTP and other stateless protocols, combined with server-side processing has severely damaged productivity. The success of this combination has created a huge divide between business applications and traditional client-side applications. Below is just a small enumeration of the problems encountered using the stateless/server-side combination;
You may be asking, why not X<add technology here>? There are many different flavors of XML based architectures from groups such as Mozilla and Microsoft. The problem with XML based architectures is that the languages which derive from it are not optimally human readable in all circumstances. XML's flexibility allows it to be used to represent just about ANY type of information. But this does not mean that it is the most productive format to use in every situation. I would argue that there are far more productive, human readable formats for creating user interfaces.
Another reason why our collaborations often fail to achieve productivity is the languages themselves. There are a number of bottlenecks in modern languages that serve to confuse the readers of that code. Languages which are easy to write but difficult to read, such as Perl, are the antithesis of collaborative productivity. Languages such as Java and C# come a long way in bringing readability to source code, but fall short in a number of ways;
I would like to continue with my thoughts on why our language has become a hinderance, but its clear to me after writing these two points, that I cannot make it fully clear what the solutions and the benefits of these solutions are without having a concrete example. We're all coders here, so its all just pie-in-the-sky until I start spitting out some real example's of the "old" way and the proposed way. I have it all in my head right now, so my intent is to begin implementing this new language and thinking through the potential pitfalls. When I get to the point of showing code, I will have a feasible, cross-platform basis for solving all of the aforementioned problems and many more.
We in the Computer Science industry have a real problem. If we don't solve it, someone will. We may not like who solves it or how they solve it. We need to work it out now while it's still in our hands. Your thoughts and comments are welcome.
Oh yeah, and what does SCRAPIE stand for? Source Code Reuse, Abstraction, Polymorphism, Inheritance, and Encapsulation. We have reuse at the class and/or method level, but not at the source code level. This is the language issue I want to solve, and will serve as the basis for a growing architecture that ultimately solves the infrastructure problems listed above.