A Note for Managers (from: Kathleen Dollard)
http://gendotnet.com/blog/archive/2004/12/16/349.aspx | Comments
I was reading Software Factories by Greenfield, Short, Cook, and Kent last night, and between the lines I was struck hard by how difficult it must be to be a manager today. The litany of problems is so familiar that it’s almost mundane in a book form, yet knowing things are desperately wrong with how we write software does not help today’s managers at all. They’ve got to wonder whether marginal success and regular failure is because of this aspect or that aspect - inadequate tools, incompetent staff, inconsistent stakeholders, etc. But these are the symptoms, the surface effects above deeply troubled waters. If we weren’t writing software on the 20th century’s version of the stone table, you could weather the ups and downs of tools, staff, and stakeholders. So I thought I’d write this entry for managers.
< ?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
Managers are caught in the cross fire between stakeholders that know things should be much better, and programmers who know traditional techniques won’t let them get much better. As the desperate and only available approach, you may have just wound the spring tighter on programmers, demanding more while offering them less - and now you’ve got that sick feeling that an expanding economy is about to pull the rug out from underneath that.
I don’t think Software Factories has the answers for you. I’m reading it because it supports a version of code generation surrounding domain specific languages/systems. I’m convinced that’s a rabbit hole sucking in the best minds in our industry, and seeing so much effort draining down that hole makes me hope I’m wrong. So I’m giving Software Factories a fair shake. After I’m done, I’ll explain why I am so skeptical on the broad arena of domain specific languages.
Regardless of their future implications of DSL, we aren’t ready for it and the adjacent set of acronyms today. It isn’t going to help you get out your current project. And you can get it out faster, with higher quality, and a more sane work environment. The techniques I use feel radical, but they build on incremental developments over many years. These techniques are broadly called metadata based code generation.
With metadata based code generation, you define most of your application in abstract terms, outside code. Depending on the mapping between your database and business objects, you can pull some or all of this information from your database. Even if you lack fidelity or have multiple layers, the information in most properties in your business objects map to specific columns in your database; having to meet defined criteria such as length and range for that column. While you rarely have to think about it, metadata itself becomes a valuable business description. The mapping and exceptions (such as what fields are readonly, or who has permissions to do what) are described in XML ready to do whatever you want with it.
In the short term, what you want to do with metadata is code generation. Once the application is described outside code, the template based code offers programmers and architects an unprecedented amount of control. They can literally change some aspect, like an aspect of security, in hours, not weeks or months. Programmers are confident that the changes they made were consistent throughout the application, and preliminary testing is limited to a single vertical path. Code generated systems offer a profound level of agility.
Code generated systems provide a lower risk. You can put your programmers and stakeholders at the table working in the one language they both understand - the application itself. Because you can get the application into the hands of stakeholders early, programmers will get the feedback they need (although be sure to include the financing stakeholders in decision making). The application can smoothly evolve from prototype to high quality finished application. And yes, you’ll save money.
If you hired an architect, he or she won’t be explaining to programmers what they want the code to look like. The architect can create or review templates and you’ll get precisely the infrastructure that expensive architect suggested, not some interpretation of it constantly degrading as shortcuts help your application get out the door.
And code generation allows you to leverage the best programmers you’ve got today, the ones that understand your domain and your organization. Software Factories quotes statistics that one in a thousand programmers is about a thousand times more productive than the least productive. My father long ago told me it was worse than that. If a programmer accomplishes nothing (or sets the project back with bad code) their cost is infinitely more than the cost of even a decent programmer. Code generation leverages your internal stars. Perhaps more important, it lets them shift their focus to topics more likely to interest them - either domain specific algorithms or infrastructure. They are likely to be happier, and if you pay them decently more likely to stick around in the growing economy. One of the hard things about being a manager today is recognizing that the point of constriction - what keeps us from making better software faster - is a lack of excellent programmers.
There are, of course, many avenues to making your programmers more efficient - training, tools, the latest languages and IDEs. But the base techniques your organization uses is an important part of this picture. You’re on a knife edge between pushing you’re organization into the latest fad of dead end technology and being mired in traditional techniques. Look for techniques standing the test of time - object oriented approaches, strong infrastructure, and metadata based code generation.