Why the hell do vendors not use version control properly

This is an appeal to everyone out there who is writing a product that is meant for an enterprise customer, you know the people with budgets and it applies to companies big and small.

When doing a project you normally have a lot of things to control

• Word docs
• Powerpoints
• Visio
• Requirements
• Code
• Test Cases
• Data models
  
• etc

The point is that its a lot of different things. What makes it easier to control things is a version control system. What makes it easier is if we can use one version control system to manage all these elements. What this means is that your tool needs to

• Store things in lots of different files, every object or important piece of information should have its own file
• Delegate version control to an external tool

There are two very very simple principles that I'm fed up seeing people screw up. Having one massive XML file that your tool "helpfully" manages is just rubbish. Not only does this mean that people can't share sections of this but it also means that structurally I can't set up my version control structures so one area has all of the requirements, docs and interface specifications all managed together. This is a very bad thing and it means your product isn't helping my programme.

The worst thing about this is that its much easier for a tool vendor to just say "version control is done by another tool, if you want a free one then subversion is great otherwise we integrate with most of the major providers". Having this elementary dumb decisions of single files is just a very very bad design decision and completely ignores how enterprises need to manage and adopt technologies.

I really don't understand people who pitch up with a tool that fails on this basic test of

"see that individual important element in your tool, can I manage that as an individual element and do a release of that without dragging other crap in"

If I'm creating a Use Case I want to version at the Use Case level, not at the repository level. If I'm creating at the Process level I want to version at the individual process level, not at the repository level. If I'm modelling a database I'd like to be able to version at the entity level not the whole schema level.

Code works like this, it would be mental to have a code versioning system that worked on every file as a clump. Yet this is what lots of packages and other tools do.

Its 2009 folks and it appears people are still building tools that can't match the capabilities of RCS let alone CVS or heaven forbid something from this millenia. So a quick summary

1. Expose your things as files at the lowest level of sensible granularity, this is normally the blobs or icons in your tool
2. Delegate versioning to an external product that does this stuff better. If you feel you have to include it then ship a copy of subversion.

That is all. Its that simple.

Technorati Tags: SOA, Service Architecture

The careful denial of reality - why muppets hate tools

Sometimes I come across posts that just nicely sum up attitudes in IT that I personally think are responsible for the issues we have in IT today. This is a great example it goes through what the writer in question wants to see and starts off with a cracker.

There is always a community of IT people fascinated by shiny code generators. IDE support for SOAP is just that. There is no more “architecture” built around these code generators than the CASE tools of the past.

Ahh yes the old hatred of "code generators" its a wonderful thing, Ruby on rails sucks for the same reason apparently.

The poster of the first article goes on to talk about "dynamic" programming styles and then trolls on about how "easy" it should be to do independent evolution of complex data centres... if only everyone would listen to their approach.

Genius.

Lets start with code generators suck. First off lets assume you aren't using binary to programme, because assembler gets compiled into binary so there is code generation there. Maybe you are using a language like Java which not only compiles (generates) the code, but worst of all it then actually hosts it in an environment where it does things you didn't ask it like garbage collection, memory allocation, talking to the operating system. The posters biggest complaint isn't about code generation its about static v dynamic interfaces and really its about the poster wanting to hand roll everything rather than actually just do the valuable work.

Code generation is a good thing, a very good thing. It makes tasks repeatable and enables you to automate parts of the cycle. Code generation for editable code has issues, I personally prefer the "magic" approach where you use facades and proxies to hide the generated pieces. The whole goal of IT should be to automate more and more parts of the process, and right now that goal should be focused on automating the communication between different systems.

The "code generation is bad" crowd are plain wrong, it reminds me of a question I asked at JavaOne in 2005 (IIRC), there was a Web Framework "Smackdown" with a JSF chap and a bunch of different OSS frameworks, all claiming theirs was the quickest to code in, while the JSF chap was claiming his was the quickest to deliver with tools.

My question was that given that GUI development should be WYSIWYG, therefore tools, weren't all the other frameworks pointless and shouldn't we just get behind the one that is designed to be tooled. One of the OSS boys flashed back with "you can't build serious GUI applications with tools"... a killing retort he clearly thought. My response was "I used to build Air Traffic Control GUIs using visual builders, and I'm pretty sure those would class as serious GUIs with anybody"... the OSS framework chappy then resorted to a classic five year old child argument of "sez you".

Tooling is a good idea, tooling is what everyone wants. People want to have pieces that are easy to assemble so they can get onto the value as quickly as possible.

There are four ways to get a new cupboard

1. Buy it ready made (package solution)
2. Buy it flat packed (assemble with simple tools)
3. Build it from raw materials (planks, nails, screws) with power tools (hammers, drills, saws) (smart custom build)
4. Build it from a tree (dumb custom build)
   

The goal of technical SOA is to make 2 happen more often, the goal of code generators and things like the JVM is to make 3 simpler. The goal of people who rail against this and what everything handcrafted is number 4.

It really annoys me when people rail against generators as a principle, and yet talk of dynamic languages or using compiled languages. It just shows that they fundamentally don't understand the environment they are working in, and yet they feel this ignorance gives them the ability to hand out advice.

Technorati Tags: SOA, Service Architecture