David Hayden shows off the Export Templates Wizard from VS05. Very cool. Frankly, I like GAT for most of this type of template work, but this really fits nicely from a “simplest thing that could possibly work” perspective.

If you haven’t had a chance to check out the most recent issue of The Architecture Journal, I highly recommend it. In particular, I liked Metropolis and SOA Governance by Richard Veryard and Philip Boxer as well as Value Driven Architecture by Charlie Alfred.

Richard and Philip dive deep on governance, leveraging Chris Alexander’s Nature of Order and Pat Helland’s Metropolis. In particular, I liked the section on the structural implications of service orientation. As per Alexander, large complex systems can’t be designed in the traditional manner – they evolve over time. This leads Richard and Philip to discuss the highly fascinating concept of asymmetric demand. To quote the article: “Asymmetry means that the forms of demand are increasingly specific to the context in which they arise.” I can’t do the concept justice – just go read the article – but my takeaway is that what you sell isn’t necessarily what people are buying. Take SQL Server for example – you know, one of those products that launched a new version yesterday. Amazing product, but nobody buys SQL Server on its own. It’s always bought in the context of a larger solution. SQL is extremely flexible, so the number of contexts in which it’s appropriate is extremely high. But still, how many business people have ever said “We need to buy a database”. I’m guessing zero. Business people say things like “We need to keep better track of our shipments/inventory/customers/orders/etc” or “we need to better insight into business trends” or “we need to be able to demonstrate our compliance with <insert government regulation here>”. These business problems all need a database like SQL Server, but they need more than SQL Server alone. That’s the asymmetry. Microsoft sells SQL Server (among other things of course, but let’s focus for a second), but customers are buying a solution to their business problem.

On the topic of business problems, Charlie’s article on value modeling flat out states that traditional requirements based design is ineffective. Charlie’s agrees with Jack and Keith that requirements define a system, not the problem the system is intended to address. As such, often critical design decisions are made while defining requirements that have drastic impact on the development of the system down the road. As a somewhat silly example, if I define requirements for a software system, I am precluding any non-software system solution to the problem. What if the best solution for a problem isn’t software? Because of mistaken assumptions I’ve made in the requirements gathering process, I’ve eliminated the best solution to the problem. Woops.

And Charlie has this great quote about the requirements gathering process:

Traditional approaches, like use case scenarios or business/marketing requirements, start by focusing on the types of actors with which the system interacts. This approach has several major limitations:

• It focuses more on what things the actors do, and less on why they do them.

• It tends to stereotype actors into categories, where all individuals of a type are essentially the same (traders, portfolio managers, or system administrators, for example).

• It tends to ignore differences in limiting factors (for example: Is an equity trader in New York the same as one in London? Is trading at market open the same as trading during the day?).

• It is based on binary outcomes: the requirement is met or it isn’t. The use case completes successfully or it doesn’t.

There is a very logical, practical reason why this approach is popular. It uses sequential and classification-based reasoning, so it is easy to teach and explain, and it can produce a set of objectives that are easy to verify. Of course, if simplicity were the only goal that counted, we’d all still be walking or riding horses to get from one place to another.

I love the point about simplicity. Often, we do things in IT that are simple for IT but that are more complex (and thus bad) for the business. For example, a web app may be the easiest to deploy for IT, but if I have a mobile workforce that web application will cause more business headaches than it solves in IT.

In other Architecture Journal related news, you can sign up for a free subscription, so what are you waiting for?

I wasn’t there, but apparently Grady Booch made a comment at OOPSLA last month that throwing away models is a good thing. Juha-Pekka’saccount of the Design and Modern Software Practices Panel has Grady saying “when the project gets closer to the delivery you normally throw away UML models. This is a natural choice since the efforts needed for keeping the design – user view, dynamics, behavior, interaction etc. – linked with the implementation are simply too high.” Ivan Moorehas Grady saying “I often throw models away but tend not to throw away the source code.”

I’ve gotta believe that this comment was somehow taken out of context and that the Grand Poobah of the Common Semantic Model doesn’t actually believe that tossing the model at the end o the project is a good thing. If we view these comments thru the lens of Code is Model, you realize this is a major violation of the “Models must be Intrinsic to the Development Process” tenet. Since code is model, it seems silly to throw out the UML model and keep the code model. The only reason I could think to do that, is because the UML model has no value.

And this leaves me wondering, exactly how much benefit does Grady Booch get from his UML model if he’s willing to throw them away near the end of the project.

I’ve gotten some great feedback on my Code is Model post. But before I get to those comments, I wanted to talk a little bit about the role of tools. Tools are important in every industry, but in no industry are they as important or central as they are to information technology.

One of the fascinating differences between IT architecture and “real world” architecture is the feasibly of automated transformation. If I have a blueprint of a house, there is no tool to automatically transform it into a house – someone has to do the actual work of putting up the walls, running the plumbing, etc. But in IT architecture, I can transform blueprints – i.e. the code – into the finished application automatically. That speaks volumes about the importance of tools in information technology.

Without the tools to automate the transformation, all IT models – code or otherwise – are nothing more than documentation.

So if we are to include models as part of our development process, we need tools to execute the transformations between levels of abstraction. But where do those tools come from? In the case of abstractions with widespread horizontal appeal, they are likely to come from language vendors such as Microsoft. For example, abstractions like generics and query expressions are useful in almost nearly every project, so it makes sense to include them in mainstream languages like C#. However, one of the key points of Software Factories is that in order to continue raising the level of abstraction, we are going to need narrow the domain to which those abstractions apply.

Developing language-based tools is currently quite expensive, and therefore makes economic sense only in broad horizontal domains, such as user interface construction and data access, where the necessary investments can be amortized over a large customer base. For this reason, commercial implementations of the Language Framework pattern are supplied almost exclusively by platform vendors.

This economic model is threatened by the trade off between scope and value for abstractions. As Jackson puts it, the value of an abstraction increases with its specificity to the problem domain. The higher the level of an abstraction, the narrower the domain to which it applies, but the more value it provides in solving problems in that domain.

We are now at a point in the evolution of the software industry where frameworks and tools must become more vertically focused, in order to realize further productivity gains. They must provide more value for smaller classes of problems. This breaks the current economic model because markets for vertically focused frameworks and tools are too small to support platform plays, and because the domain knowledge required to develop them is housed mainly in end user organizations that have not traditionally been software suppliers.
[Problems and Innovations by Jack Greenfield]

In other words, these domain focused languages, frameworks and tools are not going to come from traditional language vendors like Microsoft. They are going to come from organizations that have deep experience in the given domain, many of whom will not be traditional software vendors. I think SIs and ISVs will adopt this approach before many end user organizations do, but eventually any organization that invests in building reusable frameworks is going to want to invest in building languages and tools to automate the usage of those frameworks.

I think the best way to start developing these tools is to incorporate their construction directly into the software development lifecycle. I liken this to Test Driven Development. If you use a TDD approach, at the end of your project you end up with two outputs – the project and the unit tests. Assuming the code you’re building now (with their associated unit tests) is designed to meet current requirements, you shouldn’t need to refactor it significantly until those requirements change sometime in the future. The tests you build today become a tool to help you improve your code in the future when the requirements change. From a tool development perspective, Test Driven Development is a specific instance of the more generic concept of Tool Driven Development, as tests are a specific type of tool.

What if, instead of building code test first, you thought about building tools first?

The problem with tests is that hey are tightly bound to the current project. They may help you improve this project’s code in the future, but they won’t help you develop other applications. I think we should also focus on building tools that make it easier to build the existing project. The goal would be to be able to use these tools not only on future iterations of the current project, but on other similar projects as well.

Of course, we don’t really have the infrastructure to do this effectively today. We need to be able to make it easier to build tools, compose tools and evolve tools over time. Supporting evolution will be key since these tools will likely need to be refined as they are applied to different projects. Test Driven Development has xUnit style frameworks, Tool Driven Development needs the equivalent. The DSL Tools and Guidance Automation Toolkit are a good start, but aren’t enough to enable Tool Driven Development on their own.

Do you believe this Tool Driven approach can work? What do you think Tool Driven Development tools would look like? Please let me know.

I’ve been following the ongoing discussion about typing systems in programming languages between Ted Neward and Stu Halloway with great interest. Given that I believe Code is Model, I’m eager to mine knowledge from successful tools to apply at higher levels of abstraction. And as an employee of a language vendor, I’m also very interested in what Stu describes as vendor-oriented vs. developer-oriented languages.

So why has the static/dynamic debate staggered on for so long? I think we could get closer to some answers with better choice of terms. “Static” vs. “dynamic” is highly misleading. I propose we use a new set of names: vendor-oriented vs. developer-oriented programming…So who do you trust most: vendors or developers?
[What’s new in C#, or who do you trust most?]

With a vendor-oriented language like C#, core abstractions are much more firmly controlled by the language vendor. Conversely, developer-oriented languages like Python leave more of these choices to the developer (although they tend to provide reasonable defaults)…Competency and trustworthiness are sprinkled all over our industry, both among language vendors and application developers. My concern is who controls the abstractions. Developer-oriented languages (like Scheme) give a lot of control (and responsibility) to developers. Vendor-oriented languages (like Java) leave that control more firmly in the hands of the vendor.
[Developer oriented languages]

Personally, I think calling them static and dynamic language is far less misleading than vendor and developer oriented languages. Further, I think Stu is making somewhat absurd statements to garner attention. However, I believe he’s certainly onto something with regard to the language abstractions. The abstractions I and my team care about on our project are almost assuredly going to be different from the abstractions you and your team care about on your project. Having a programming environment that enables the abstractions you need on a given project is very very important.

The problem with Stu’s argument is that he’s focused on low level language abstractions. Abstractions like “inheritance, encapsulation, delegation, how symbols are interpreted, etc.” Are you kidding me? Projects don’t fail because developers can’t change the language’s concept of inheritance. They fail because the gap between the abstractions provided by the language and the abstractions needed by the solution are enormous. Modern software development is like building skyscrapers with Lego blocks. Furthermore, projects fail because business and IT don’t speak the same language. Business people don’t care about concepts like encapsulation and symbol interpretation. They care about concepts like ROI, business plans and regulatory compliance. Geeks may not feel comfortable talking about those concepts, but they are what keep a business in business

Imagine your CFO listening to Stu and Ted discuss these language abstractions. They would be thinking “What the hell are they talking about?” To Ted’s credit, he bluntly states that he doesn’t trust developers which would likely put him in well with the CFO:

I see the same concern every time a developer starts talking about doing bytecode manipulation at load-time–just because you can doesn’t mean you should. In this respect, I trust the guys who’ve been down this road before much more so than developers who are just coming to this and are starting to flex their new-found freedom and will (undoubtedly) start building systems that exercise this power.
[Dynamic languages, type systems and self-modifying systems]

I wouldn’t go so far as to say I don’t trust developers, but Ted’s point about can and should is spot on. I’m sure there are scenarios where bytecode manipulation is critical to the success of the project. Hell, in the project I’m currently heads down on (hence the lack o’ posts in the past two weeks) I’m using much more reflection and late-binding than I ever have before. Not because I can – frankly, I like static typing – but because that’s the best way to solve the problem at hand.

It’s important to keep the big picture in mind when discussing minutia such as a given programming language’s core abstractions. IT exists to serve the business, not the other way around.