Looking for Development Shangri La.

Blogging for the first time reminds me of the" tell me what you did over the holidays" task at primary school - lots of pencil chewing going on and looking out of the window.

I am a software engineer although i have had many title changes due to corporate restructuring but in old money i am still a kind of software engineer i believe. After a good few years (ok about 20) in the software industry, a few things are becoming clearer and some are becoming even more difficult to understand. While my colleagues are excited to to look at the new languages and platforms  I am more interested to notice even on the bigger projects i am trying to resolve the same problems as i was twenty years ago just with different tools. 

Wizzy things.

Actually the tools are part of the problem. I am working on a complex project but the will to create a new tool that does something a bit wizzy things still rules supreme. In our industry everyone is a secret wannabe softie so usually the creators of the tools don't come from one of the formal software depts. (mathematicians take note) the creator then disappears leaving the production team to either discard or support what is usually substandard code (pique) in a tool that has embedded itself deep in the data production process. The antithesis of this is the big tool approach uml added value. This is usually some sort of model that everyone will comply to, but that no one can explain. The big model approach can be one discipline teams own world view of how everyone else should be working.

Deep suspicions

 Lurking deep behind the dream of standardisations and freedoms come other overriding problems. In the science and engineering world software is still a newcomer and under deep suspicion of being "money for old rope" or paying for something that appears to have no tangible evidence of production. This jaundiced view is partly our own fault as the demonstration or visualisation of software functionality to a project management team takes time to work into the schedule alongside all the other activities although increasingly essential and software people don't like to do presentations (apologies for big generalisation). 

Pushing and shoving

The relationships between disciplines seems to be key now, the increased understanding of the others environment and behaviours essential. The acceptance of the need for different views/formats and tools to exist and evolve supported by a common development community (after much pushing and shoving) appears to be the most effective (however messy that may look to management). One reason   why the maker community is of such interest. Showing respect for the people that have made stuff made with respect for others that may re-use it works.This may seem a development shangri-la but we can't move forward without it.

Cheaper Thrills

If development Shangri la was housed in a building then the technical/science community should demand corporate bodies take the complexity of large tech/science projects seriously, there are algorithms and models designed to build buildings that enable collaboration and interactions(see Christopher_Alexander.) wouldn't where you sit/work 8 hrs a day or more)impact on development output. Business keeps looking for a cheaper thrill, even asking for voluntary contributions that it can exploit but what added value will the corporations finally bring, will engineers/scientists of the future really need them? Its a good time to bring mutual respect and as they say in the  (Makerspace)  maker community "be excellent to each other!".