New Workflow Tag!

Thanks to everyone who came to my two workflow talks at DevConnections. Thanks so much for tolerating the overflow conditions. You really stoked me back up on workflow, and I’m ready to roll for my all day session in Los Angeles Dec. 1.


I’ve started a new tag here for my workflow musings.


 

Thank You for the Carrots

I live in a wonderful world. Sure sometimes people’s own unhappiness and agendas get in the way, but most of the time I am surrounded by kindness. And so are my children. Children need the great gift of building the stories of their lives – experiences that they remember and build themselves on. But as parents we are not the only ones that give these gifts to our children.


Halloween night a group of 15-20 year olds set out trick-or-treating from my house. There were a few cross-dressers, a cat with red ears, a very cute clown and a musketeer named Samuel with a frying pan. It was one of those beautiful loud vivacious groups celebrating each other. As the girl-clown said “I was just sitting home when they called wishing _I was cool enough to be invited to a Halloween party”. All arrived dressed. None were ready. The one that remembered a bag forgot a coat and as the temperature plummeted I supplied a pink raincoat to the guy in lingerie. Only on Halloween. To the rest I gave grocery bags. One tall young man in a funny green coat and at least two odd hats was not trick-or-treating, just coming along.


For my part, I did little else but feed them. I disengaged from the game of trick-or-treat this year as another excess of indulgence designed with the sole purpose of making corporations rich. But with my house full of these young people so happy to be together with the drama of teenhood set aside for the night, a little part of me wondered if I should get candy and turn on the porch light.


They were late, of course. But headed down toward the one house they couldn’t miss. The artist with the yard full of spooky things.  He came to the door and said “I’m sorry, I’ve run out of candy”. I’m sure every other kid from three miles round also wanted to climb passed the body in the noose, and inch passed vague bloody things to climb under the 12 foot tall ant (or was it a spider without a web) to ring that doorbell.


In response to the no candy announcement, the tall non-trick-or-treater with the funny hats and green coat said “That’s fine, I’ll take a toaster”.  The artist said “wait a minute”.


Thirty seconds passed and the group wondered if they had been rude. A few more seconds. Surely he didn’t have a spare toaster? Bbut he’d asked them to wait. Hmm. What to do… as he reopened the door.


Turning to the young man with the green coat and funny hats, the artist said “For you, carrots” and handed him a can of carrots.


Performance art at its finest.


A moment turned upside down.


A story retold to me. A story that will be told a hundred or a thousand time more. A story that helps my son understand what it means to be gracious. What it means to allow the people on your doorstep their moment in their world touched sweetly by yours. What it means to turn someone’s joke upside down. What it means to be kind.


Thank you for the carrots.


Thank you for all the little things you do today to bring a smile.


 

A Sufi Tale

To understand my world view, you must know that I painfully came to grips with something described in this story that I heard as a Sufi tale (badly told here, I’m afraid):

A farmer had a horse he used to till his field. One autumn day, the horse ran away. The farmer’s friends came by and offered condolences. How would he till his fields in the spring? How would he survive? The farmer said “I cannot know if this is good or bad” Several weeks later, the stallion returned with a beautiful mare. The farmer’s friends came to offer congratulations! How wonderful? The farmer said “I cannot know if this is good or bad” Sometime later, his son was breaking the mare. He was thrown and crippled his leg. The farmer’s friends came and offered condolences. How would his son find a wife and have children? Who would care for him when the farmer when he became old? The farmer said “I cannot know if this is good or bad” A month after there was a war and the emperor sent soldiers to conscript the young men of the village. The farmer’s son was left behind because of his injury. Sadly the young men did not return from the war. Each year the mare had a beautiful foal and the farmer gave each to one of his friends for being so kind.

This is the moment we live in. Much of this moment we make for ourselves. It is OK to celebrate and mourn. Emotions are as a much a part of life as breathing. But to declare true value in the events of our lives – to allow them to be good or bad within our psyche is the recipe for an unhealthy kind of desire. To wish for something to happen or pray it will not happen says we know what will be good and what will be bad. As soon as we step into the quicksand of such unhealthy desire, we unleash the Pandora ’s Box of fear. We fear something will happen or not happen. This fear can freeze us, and it almost always puts a veil between us and the beauty of the one moment we are sure of – the moment we are holding right now.


 

Among Bytes

I’ve started a new tag called “Among Bytes.” This name honors one of my oldest and dearest friends and favorite blogger – Len Bullard’s “Life Among the Mammals”. Anyone who wonders when I get homesick for Alabama or why I was horrified when an otherwise intelligent person referred to a Titan booster as the Space Shuttle should read Len’s blog.


The trees fall yellow and gold and it is breathtakingly beautiful in Colorado today. I want a place where I can talk about life and travel – and maybe even spirit, politics, and what I did to kill the planet today. Maybe about the battle I have with my weight, how fabulous my mother is, or how hard it is to learn to play the violin.


I have a fabulous life. I’d like to talk about that as well as all that grimy .NET stuff.


 

What? No Code?!?

When I say things like “writing code bad, other stuff good” it comes out sounding radical and there a couple natural points of pushback. The most significant one is “yeah right, we put our business information in something else and that changes too – so we’re trapped forever in technology and like being addicted to food we just can’t stop”


Let’s nip this in the bud. The key difference between code and storing expressions of the intent of our app is that you can recognize, categorize and morph declarations. Sure, the syntax of any declaration is based on the technology its intended for. Just look at the massive difference between GenDotNet metadata and the metadata behind entity framework which solves a critical subset of the same problem. But, any metadata worth its salt can be transformed into any other metadata syntax. That’s why I’m excited about seeing the entity framework tools work tools work well. They create a standard mapping for any code gen anywhere. It’s just messy transformations that we know how to do.


Code is the opposite of isolation. It’s such a convenient mechanism that everything is thrown together. It’s ghoulash when we need a wedding cake.


If I write code for CSLA, the details of my classes are heavily influenced by the superstructure of Rocky’s library. I’m going to bury my stored procedure, parameters, data reader assignments, authorization, validation, etc into VB or C# code related to a specific library. All of these specifics are also required for a different library and a different set of libraries or C#, VB, Ruby, Python, F#, Post#. By separating out the known aspects of the job we’re doing – we can use it or not use it in the next great thing. I may not use the stored procs in Entity Framework.


While I have a lot to say trying to jar your world view into seeing code differently, it’s exactly that:  kicking your world view. Code remains critical for two reasons. I generate my code, but I have to create code, not some other magic. If I don’t have code, I can’t debug. That’s one of the many, many things we forget about the 4GL disasters of the late 1980’s – you could no more debug the crap than fly to the moon. Imagine writing an application designed to run a refinery and hearing the programmers say “I don’t know why it does that, but try something that worked another time I didn’t know what to do”. A refinery! In a generated system, code becomes how the system tells you what it’s doing more than the reverse.


The other important thing about code is that as we move away from code as core way of expressing intent – the code that matters cannot be moved. You find business logic simply because it remains when all the potentially declarative stuff is removed. How exquisite we can make the code we have to write when it stands alone and we address it as a primary purpose of our existence. And how much more if it we’ll write when we aren’t busy plunging the toilets of our application plumbing.


 

Legacy Lessons

Visual Basic 3 to Visual Basic 6 had many lessons to teach us. We did not as an industry learn these lessons, so we are in the midst of repeating them. One of the most important lessons was not to combine business logic and user interface code. Well DUH!


But, why not? I don’t mean to be rude, but I’d really like to shout in your face and make you truly understand. Fly to Tibet, climb a mountain and meditate in a hut for a month until you can answer that question. Why was it bad to combine business logic and user interface code?


Which of course you probably can’t answer because we would not have been so stupid, as an industry, to make these mistake second time around if we’d gotten it the first time. Combining business logic with any technology dooms it to be rewritten from the ground up when we get a new technology – and code is technology. DOH!


You cannot combine technology with business logic. You cannot combine code with business logic.


The shiniest, prettiest toys and languages are tomorrow’s legacy. Except for movements away from technology and code, everyone at Microsoft if building tomorrow’s legacy tools.


Don’t tell me it’s impossible to change, .NET had all the underpinnings to do metadata based code generation, rules engines, and other techniques in the first release. I’m not the only one who has been using alternative development techniques. Sure it’s hard. It’s really, really hard. It is too hard for you to do individually on your project. Changing our development efforts so fundamentally that we treat code as a necessary evil is such a fundamental shift that we need combined efforts, tens of thousands of man hours and significant leadership. In today’s world, leadership means either Microsoft or standardized, combined third party efforts. The third party has made great advances in niches, but no full-scale strategy. It’s time for Microsoft to step in.


Several things are happening right now. The current crop of technologies will teach your team the painful lesson that .NET is not an inoculation protecting your project from technology change.  We have legacy .NET code. That sucks. The solid foundation of .NET actually does the opposite of inoculating your application from change. It speeds up the pace. Microsoft can build amazing new toys – so they do. 


Another thing happening right now is that forces are moving behind the scenes to make it easier, or at least more standardized. LINQ to XML in Visual Basic offers XML literals which have amazing possibilities for code generation. Today, it’s better in some ways and worse in others to CodeSmith, but there is a real possibility it will unseat XSLT for complex generation. We need to work out a boatload of patterns which I’ll take many posts to cover, but you can get a peek in Beth Massi’s blog. Also on the horizon is Entity Framework which offers a standardized way to map to metadata. I’m spending time customizing the architectures for a talk at DevConnections, which will make a great blog post later. Other things just below the horizon will also make your generation easier in the future. The earth is turning.


Before letting the details of new technologies and code generation techniques start swirl around you like a blinding swarm of butterflies, take a deep breath and go to a mountain, or whatever you need to do to focus your breath on what business code is. It’s not plumbing, and it IS aspects of your UI. It’s not technology; it’s not anything repetitive between your classes. Encourage conversations about finding all of it, and let the rest of this decade be about isolating real business knowledge in all the places it resides: database structure, service contracts, test definitions, logic rules, workflow, business object code, validation rules, authorization guidelines, user interfaces, etc.


 

The Changing Picture of Code Generation

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.


 

Upcoming INETA Tour

Tomorrow I set off for a five state, six city INETA tour with three brand new talks. This is part of giving 27 talks in 90 days, which is about as crazy as it gets (check www.gendotnet.com for my schedule).


I know most folks reading this will not be able to make these dates, but I wanted to share some perspective on what I think is cool about each of these talks, because it gives some insight about how I am thinking about these things. Of course if you’re near any of these locations, please drop in.


If you are part of an INETA group, I’ll have these (along with about five more) on my list for talks next year. If you aren’t part of an INETA group, why not? It’s a great way to network with peers, and great content from a range of local, Microsoft and INETA speakers for free. I’m still up in the air on my Q1 schedule because I’m looking for an English Springer Spaniel puppy (crossed or field, suggestions welcome), and when I find one I’ll have to be mom for a while.


.NET 3.5 Language Improvements (Huntsville, Tuesday 10/9/07) – NEW: Thanks to Sujata’s encouragement, I’m going to dive into combining a C# and VB 3.5 talk. A lot of the stuff, the underpinnings of LINQ and the myriad of cool things we can do with it are the same in both languages. The difference is syntax. By combining them I can show some of the cool XML extensions for VB. For some problems, these extensions are important enough for a C# team to justify a few VB modules to access this goodness. I think it’s important for everyone to know what’s on the table in both languages so you can pick the best tool for the job in the rare cases it matters.


WPF – Beyond the Bling (Little Rock, Thursday 10/11/07): This is not a new talk, but it’s one I am happier with each time I give it. WPF is an awesome platform and I think to get it you’ve got to spend some time with XAML – maybe a lot of time because the designers suck so badly. My main theme in this talk is what it really means to separate appearance, behavior and layout and why layout is the long term investment.


WPF Custom Controls (Nasvhille DevLink, Saturday 10/13/07) : I gave this talk at SDC just barely able to keep from falling asleep as I fought off jetlag. I’m looking forward to enjoying the talk a bit more this time. A core piece of this talk is actually showing you when NOT to use custom control s – an array of scenarios that we needed custom controls for on other platforms where WPF has a better story. Then I discuss scenarios where your own controls make sense – both to hold a subset of your UI in a user control and to offer a different programming interface.


Metadata Key to Code Generation (for architects) (Nashville DevLink, Saturday 10/13/07) – NEW: DevLink should be fun with a chance for me to get together with my buds Rocky, Scott, Billy, and a whole bunch more. I’ll be giving an architecture talk, which is always interesting for someone so invested in code. But 90% my code is generally generated, so I’ve got a lot to say. When it comes to code gen, I think it’s all about metadata, and Microsoft’s Entity Framework just underscores this.


Rethinking Object Orientation (Mitchell, SD and Michiana, Monday and Tuesday 10/14 and 10/15/07) – NEW: This talk debuts things I’ll be talking a lot more about in this blog. Object Orientation Design in the traditional sense has become unimportant at best, and damaging at worst. I have over twenty things that have fundamentally changed since Booch’s work in the early 1990s. Since I was a hard core disciple, this rethinking has been challenging and sometimes very disconcerting. At the end of the day, I think there’s a clear strategy for moving forward with today’s applications – and I’ve gleaned it from talking with hundreds of programmers about what makes their own designs sing (or groan).


Refactoring with Generics (Fort Wayne, Wednesday): This is the talk I thought had a six month life two years ago and it’s still one of my most popular talks – I’m giving it three times Aug-Dec. Generics in the framework have a huge potential to make your code more robust, and a little faster along the way. I talk about this, and understanding what generics really are (I even compare them with C++ templates if there is a C++ programmer in the house). But I go beyond this to show how valuable generics are in refactoring your object hierarchy – you can simply move more stuff into generic base classes, even while you need to retain the non-generic base.  Seeing this come together to reduce the code base by 50% is pretty impressive which is part of why I think this talk lives on.


 

.NET Source Code

Wow!


Like I didn’t have enough to do already, Microsoft will now let me download and peruse the .NET framework source code. Talk about exciting Saturday nights.


In all seriousness, this is very valuable for debugging. There are places the framework goes south and it’s hard to figure out why. This will help with debugging scenarios, and will be easier to use than Reflector in many other scenarios.


I am a little worried that at a time VB is finally coming into its own (XML LINQ, My, announced DLR support , etc) that this source code release for the first time makes it relevant whether you are writing in the same language as the framework.


My simple answer to that is that we already lived in a world where every VB programmer should be comfortable reading C# and every C# programmer should be comfortable reading VB. In the first case, samples are coming out first in C#, a few scenarios require C#, and now the framework will be in your debugger in C#. C# programmer’s need to be able to read and code in VB because there are some very common scenarios where VB is easier and ignoring the world of dynamic languages is just silly. The common scenarios include the occasional late binding scenario, interop with Office (unless you are very fond of redundant Missing.Value) and XML scenarios under .NET 3.5.


As each language evolves to have cool new features, there will be increasing reasons to mix languages in applications so we are using the best tool for the job. With snippets and Intellisense, crossover is really not so hard, although it infuriates me that the teams won’t take seriously explicit crossover features like quietly removing that stray semicolon that wanders into my VB application.


All of which is off topic. Three cheers to Microsoft for releasing this source code!


 

Welcome

I’m back blogging. Too much to say, too much to do…


Bill says that Susan scares all the spam away. Spam killed my previous blog, and I can’t see blogging if you all can’t talk back.


Hopefully it will be a fun ride

Just another Microsoft MVPs site