I’m excited that a lot of forces are coming together, slowly, to bring code generation into the forefront and I want to talk about my experience doing primarily code generation on the majority of my .NET projects for over five years. There are a lot of things I’d like to talk about and this is the start of a series.
I’ve done a lot with code generation. I even wrote a book. I’d like to slice out the parts of the book that are dated, but there is so much I want to say about code generation and there won’t be another book for at least a year because things will be very dynamic for code generation in the next year or so. Instead, I want to use this blog for serious dialog on the challenges and nuances that we’re going to face. This is what I’ll do this year instead of books, and maybe later I’ll pull together these ideas into a book with a formalized structure.
In putting code generation in perspective, I wish I could talk more about the one project that didn’t use code generation. The team was so awesome and struggling so much that I was happy to sit on the edge with a side task and watch it all come down. I don’t regret the experience. Here was the highest density of great programmers I had ever seen with almost every process issue aligned for success. This was a very, very smart software company. They had money, management support, teamwork, a well defined problem, agile methodologies (at least somewhat), and comparatively a lot of time. But even success is failure. Everything they did will go in the trash can. Even if they succeed they will fail in that the whole thing will start over with a new technology.
It was also nice not to be the .NET Goddess (yes one of my partners uses that on my business card). They had no clue who I was when I came to work, just a coder reassessing and picking up some side work. It turned out to be a far more intense and long gig than I wanted, and it had its share of ups and downs, but it gave me a chance to see the best of “normal” programming; as close to a fly on the wall as I will ever get.
What I learned from this experience is that even the best normal development efforts are worse than mediocre code generation development I’ve done. But, I start with an arsenal of tools that you do not have. Without these tools, code generation is so hard to do well that I can’t even suggest the average shop incorporate it. This is what will change in about the next year. It makes no difference whether these tools are mine or someone else’s. Other people have a lot more time than I do. But you need to understand, and people with the product s in the code generation space need to understand what you need to do code generation well. The purpose of this series of articles is to output my share of knowledge on that subject. To understand deeply, I have to talk a lot. I am not wise enough to distill this into bullet points – beyond the principles I’ve already defined in my book (and will cover here soon). I want to start a conversation – in you blog if you have one – where you disagree or have more to say.
Once code generation is laid out with more clarity than today, it’s time to talk BDD. Actually I want to take just part of BDD (the artist previously known as TDD). I do not think proper development is a “Holy Grail” that is unreachable. I believe it is a reality we will hold in our hands within five years and will be a combination of code generation for all the stuff its dumb for us to write married to a highly morphed BDD for all the code we do have to write.
Of course at that point, we will have uncovered a new layer to explore – but where we have been stuck and the pressure is so great – this will be solved. It’s time we got started.