Improving Software Development Practices Through Blueprinting
Blueprinting MotivationHaving produced a blueprint for an aeroplane it is feasible to hand it over to three different mechanical engineering firms from different corners of the world and expect them to produce three aeroplanes of almost identical composition. This is because the unpredictable inspirational thought has been completed before the blueprint is issued and only well-defined procedural activity remains. The same can not be said of the software industry, which traffics in diagrams and descriptions that require a great deal of programmer interpretation. Indeed, three software companies tasked with developing a software application based on such descriptions would produce quite different solutions. At present the software industry develops applications from models. This is analogous to going to a builder and asking him to build a house from a plasticine sculpture. The builder would have to adopt the role of architect and undertake the problem solving and requirements analysis that only a fully-fledged architect is qualified to perform just as software engineers do today. The software industry has struggled along with this approach but the impending challenges of multicore and the concurrency revolution and the continual rise in software complexity demand improving software development practices using the approach of mature industries before us - specialization. Improving software development practices through effective software blueprinting requires three important components:
Language for InfrastructureIn order to produce a software blueprint, it is essential to have a language that is capable of describing the application infrastructure. Electronic engineers have circuit diagrams, mechanical engineers use scale drawings and so on. In the case of software, this language must meet the following constraints:
The Concurrent-class Description Language (CDL) is an example of a software blueprinting language where the level of abstraction is just right. Supporting TechnologyA wonderful property of software is that because its creation does not involve fabrication of physical parts, once a prescriptive blueprint has been produced, the software production is largely automatable. This requires a supporting technology to translate the blueprint into executable code. The ability for an architect to describe an application at a high-level and have it automatically translated to code is important in improving software development practices because this means that the intentions of the architect and domain expert are directly realized in the delivered code rather than being subject to programmer interpretation. Typically the application infrastructure is translated by machine. Sequential processing code, which may be expressed in numerous different forms as convenient (e.g. Pseudocode, Flow Chart, State Diagram, Matlab etc.) is translated to code by software engineers. Role SpecializationThere exists a natural specialization in the mature construction industries between the architect and the builder. Blueprinting and the infrastructure-oriented approach prescribes the same division for improving software development practices within the software industry. The most highly-skilled engineers and domain experts become software architects and are primarily responsible for application blueprinting. The remaining engineers are divided by discipline rather than by domain expertise. Some examples of disciplines are:
Again, drawing the analogy with the building industry, this is equivalent to specializing as a plasterer, carpet fitter or electrician. If the building industry was divided by domain expertise in the same way as the software industry we would see builders specializing in schools, hospitals or perhaps bedrooms!
|
