Everywhere I turn, all I read about is dynamic languages. Apparently, there is a small yet growing contingent of programmers that think dynamic is the only way to go. These guys are frustrated with the shackles of static type systems that force them to write clean code. And apparently, there is also a small and growing contingent of media types that think “hey, there’s a buzzword I haven’t heard before, let’s use it until we wear it out.” And they have. Believe me, its paper thin and about to be ripped through like a rubber eraser pulling double duty.
However, I’m not here to debate the virtues of dynamic languages. Some of these languages have really cool features, but that’s beside the point. It’s the dynamism that’s at issue and for some purposes dynamism is simply the better model. When you are dynamic you don’t have to know upfront the correctness of any particular thing. You just do what feels right and let the runtime figure out the rest.
That’s why I’m here today advocating the next logical step. It’s not enough to simply have dynamic languages. Sure, they make some of your programming tasks a bit easier to perform, but how much time do you spend programming anyway? Most developers produce on average one line of quality code per week. It’s not that they are lazy; it’s just that the ‘coding time’ turns out to be a small fraction of the overall product cycle.
So as you can see, what we really need to do is to take the advancements that dynamism brings to programming languages and apply them to those other things that busy your day.
Dynamic Meetings – Don’t plan specific meetings with agendas. Just show up in a meeting room at the same time everyday. It doesn’t have to be the same room, just pick one at random. At five after the hour, go around the room and ask each person that happened to show up in the same room as you what they’d like to talk about, write it down on a whiteboard in some order and then have at it. It doesn’t matter if you don’t have enough context to have a meaningful discussion. No one is listening anyway. It’s a good meeting if someone spontaneously decided to bring donuts.
Dynamic Design – This works best as part of a dynamic meeting. Take notes, but not too many. You wouldn’t want to fence your ideas in too soon. Doodling helps the creativity flow; be sure to use multiple colors. Don’t worry about getting agreement or buy-in from others, they aren’t paying attention anyway. They are working on their own ideas and drawing their own cartoon stick figures. When you think you’ve got a good concept, go away and write some code. Eventually, everyone will figure out something to do and will be busy writing code too. Don’t worry about integrating it all together. Its all just code, ones and zeros, adds, shifts and branches. The runtime knows what to do with it.
Dynamic Testing – Don’t make a plan. Don’t do code coverage, write unit tests or abide by any particular testing methodology. Let the runtime do it for you. Just load the program in ‘Test Mode’ and execute. The runtime will proceed to apply a series of random tire-kicking algorithms that will give the dynamic code a good workout. Believe me; you couldn’t have planned it anyway. With dynamic code you’re never quite sure what it does until you run it.
Dynamic Debugging – Yes, even dynamic programs will have bugs, though you might not ever know for sure. If you think the code is acting flaky, you may want to do something to fix it. It will probably mean looking at the code or some facsimile of it in some tool that will help you understand it. The old-school way would have been to use a debugger, set some breakpoints and walk through it, observing the behavior, looking at variables, etc. But that would require too much static knowledge about the code, things like specific variables, types, and ‘lines’. Since we’ve done away with these antiquated notions we’ll need a new style debugger that will help us deduce the problem without actually using any particular facts, a precognition engine if you will that uses advanced artificial intelligence techniques to divine the future. It’s either that or printing out text.
You see, if we take dynamism just one step further, we can vastly simplify the work we do now, by offsetting the part about doing a good job and getting it right until sometime later when hopefully we've moved on to another project.
But I digress