Too much Magic spoils the project
A lot of writing good software is, pure magic. A good design that can hold up to (anticipated?!) changes, innovative "ways of seeing" - or organizing a GUI, workflow, data elements - how to attack the problem. Its what makes the decision, optimization, and simuation solutions that my company writes, to me anyways, more interesting than simple database transactions. And there is true magic in how we develop parts of these appplications. Too much magic, and the project never ends.
See, thats the problem. Take one of our simulations, that operates the entire electric grid, generators, buses, powerlines, fuels (delivery, burns, accounting), pollution, weather, load, new generators being build, price forcasts - the whole enchalada - there is true magic in how the center of that engine works.
But just outside that, there is a large engine of simulation, that while advanced in its design, after our company has been writing this kind of application for over 34 years - - we have some pretty time tested patterns and methods to get it done. And just outside that is a nice big I/O engine, and GUI, and other - -impressive, but not mystical stuff.
And the non mystical stuff can be reliably estimated, clear requirements can be written, test cases can be documented prior to construction, and testing can occur. CMMI level3.x, nothing to heavywieght in process - but enough to provide progress transparency to management and our customers.
problem is, your best programmers focus on the critical center of the engine, the magic part. And they should, its high risk and mentally challenging. Only don't use the "process" (or lack of it? ) - iterative discovery and eureka! moments, for that part of the application, as your process for delivering the other 1-2million lines of code.
If you use too much "magic process" - your project may never end. You won't have transparency into where you are , what parts are running away in cost and time, what parts are not being vetted in requirements and design with others (we can find our design errors in the field! we are manly programmers!).
Magic is a nescessary part of our applications. But just a pinch will do.
See, thats the problem. Take one of our simulations, that operates the entire electric grid, generators, buses, powerlines, fuels (delivery, burns, accounting), pollution, weather, load, new generators being build, price forcasts - the whole enchalada - there is true magic in how the center of that engine works.
But just outside that, there is a large engine of simulation, that while advanced in its design, after our company has been writing this kind of application for over 34 years - - we have some pretty time tested patterns and methods to get it done. And just outside that is a nice big I/O engine, and GUI, and other - -impressive, but not mystical stuff.
And the non mystical stuff can be reliably estimated, clear requirements can be written, test cases can be documented prior to construction, and testing can occur. CMMI level3.x, nothing to heavywieght in process - but enough to provide progress transparency to management and our customers.
problem is, your best programmers focus on the critical center of the engine, the magic part. And they should, its high risk and mentally challenging. Only don't use the "process" (or lack of it? ) - iterative discovery and eureka! moments, for that part of the application, as your process for delivering the other 1-2million lines of code.
If you use too much "magic process" - your project may never end. You won't have transparency into where you are , what parts are running away in cost and time, what parts are not being vetted in requirements and design with others (we can find our design errors in the field! we are manly programmers!).
Magic is a nescessary part of our applications. But just a pinch will do.
Comments