5th Generation Languages
Workflow development systems are powerful, and they again have opened up the programming possibilities, but there are inherent limitations with all of them. Some limitations are a good thing, and many workflow systems have plugin-type interfaces to do things that aren't intuitive or performance friendly with the out-of-the-box toolset. These kind of systems serve up niche markets - at least until KDF comes out, but that's a beast of a different color from the ground up.Higher generation languages suffer from the same issue that plain and simple OOP does - there is a very serious separation between documentation and the end result. It makes testing difficult - because even in very strictly policed development environments, programmers don't always account for the full set of ramifications of their code in their documentation. Additionally, there is absolutely no tie between project decisions and implemented code. When somebody asks why a particular feature exists, or asks that a particular feature gets changed, the end user community is reliant on undocumented information being conveyed to the decision maker. It could be tribal knowledge that the development team shares when a given requirement does not make sense from a technical perspective. It could be information about past project decisions that only a handful of people were ever aware of. The fact that there is no link between documentation and development slows down iterative development considerably - and turns abandoned projects obsolete quickly.
DDP - a new paradigm
Documentation Dependent Programming is my own new concept. With all of the bells and whistles found in IDE's, and all of the common knowledge these days surrounding relational databases, we now have the realistic possibility of tying application documentation with application code. Certainly, if you are doing follow up development and you use a strict development model involving bug tracking, source code control, and change management, you can keep track of code changes and link patch files with bug fixes, but in all my years of development and in all the poking around I've done on both open source and commercial products - I have yet to see a system where the logic in the system is actually tied to a textual representation of what the developer intended or why. Certainly, I've seen and built well documented/well commented code - but that's not really what I'm talking about.With DDP, you really would need a well structured requirements interface. Something that could be easily parsed into and rebuilt from a relational database. I say relational database because you would want a clear separation of initial requirements, enhancement requests, bug reports, and other such things that could arbitrarily be defined for a particular project or within a global namespace. You should be able to look at a piece of code and decide with very little background information whether or not a particular function was well written and whether it took into account all of the potential situations in which it might be called. You also should be able to discern whether or not a piece of code could be updated without harming other parts of the system. Frequently, the situation occurs where a bad piece of code becomes something other pieces of a project depend on. This makes fixing things more difficult because first you have to search for dependencies, then you have to evaluate the ramifications of making an update, and finally you have to perform the update and any other related updates. Only solid regression testing will ensure that you aren't breaking something unintentionally, and I have personally found that regression testing is not performed universally.
Also with DDP, because you are forcing a relationship between code and requirements, you have the opportunity to update your documentation as the developers truly understand the particulars of a given requirement. A requirement may need to be updated to reflect a reasonable limitation. A requirement may be unclear and need clarification before code can be updated. A requirement may turn out to be ill advised - and you would want to track that a requirement initially existed, was analyzed, and rejected, so that the analysis need not be performed in the future.
I like the idea of structured requirements and structured code because not only does it make a lot of development issues go away, but it also makes user friendly documentation an easier task to accomplish. If you want a feature list, you can simply query the requirements database. If you want a process flow, build one automatically from either the requirements data set or from object and code definitions. How easy would it be to build a training guide if all of the technical questions that came up had easy to find answers? How easy would it for an external developer to begin helping out if the original decisions behind the development of the software were easily available with no communication requirement? Easy access to foundational information makes for a very efficient rapid application development environment.
Anyhow... just an idea :)
Moving Past OOP Interaction
