The problem with most advanced software development techniques is that you need to get buy-in from your boss, customers and business people. This is true for most information oriented techniques also.
However, there is an information opportunity for programmers that you do not need to get buy-in for because it is likely to be also part of your job already. Writing code that gives you information about your code is already part of you job. It can help you code faster with more reliability. You can write code so that information in you code can help you write code.
This stuff is easy because the two main difficulties are handled. 1) Code that tells you about your code can already be assumed to be part of your coding job and your boss does not even need to know about it. 2) If the information code to reveal information about your code were easy, you would have both aspects covered. It actually is pretty easy.
Some examples of this that I have written are:
- Unit tests, (once you move beyond Boolean, you can have very powerful messages).
- SQL error analysis code.
- Endematic exception handling and unit test messaging. (I’m working on the this).
- Code that gives you messages on how to fix the code.
- Sanity checks.
- Code that produces a string to allow you to copy and paste a particular call for a stored procedure into SSMS.
- Code that tells you how to implement certain not yet implemented functions.
The other advantage of these approaches is that they get the software developer used to the idea of working with information, and they build the information oriented base of libraries needed to move to the next level in This Stack.