Well that was ridiculously easy - will let it run for a while - could get a bit non-bloggish in content.
However, as a lesson in potential for future programming its all a bit frightening - seriously impressed!
Leaving to mature for a few days ......
All things computing, software engineering and physics related! Now also including retirement stuff.
Tuesday, 6 May 2014
Leveraging the New “Natural Growth” – Megatrends, Accelerators and Risks | @scoopit via @LeadershipABC http://t.co/OzCFSWKRjN
Leveraging the New “Natural Growth” – Megatrends, Accelerators and Risks | @scoopit via @LeadershipABC http://t.co/OzCFSWKRjN
— Gary Bamford (@grandwizz) May 6, 2014
from Twitter http://ift.tt/1iXNDKw
May 06, 2014 at 01:45PM
via IFTTT
With a bit of luck I have just connected my tweets to my blog by 'programming' @IFTTT - will be well impressed if it works!
With a bit of luck I have just connected my tweets to my blog by 'programming' @IFTTT - will be well impressed if it works!
— Gary Bamford (@grandwizz) May 6, 2014
from Twitter http://ift.tt/1iXNDKw
May 06, 2014 at 10:07AM
via IFTTT
Programming the Internet!
Going to trial an app that let's you connect various social media and sensors through a simple programming language - IFTTT- standing for If This Then That.
Results of one of these programs hopefully will be posted on this blog as tweets.
Here goes - entry into a whole new level of computing!
Thursday, 24 April 2014
Carve up ...
How effectively can you carve up systems engineering tasks and manage them as separate elements?
Sounds like a plausible approach to running a project or setting up contracting arrangements for a large project. Can you do this? It runs against the ethos of a systems approach and the systems engineering practice.
Businesses - which are effectively large systems of systems - these days are floundering towards more flat-open type management structures. This engenders emergent control within the workforce and more fluid problem solving as teams can form quickly and then disperse. Sounds agile - as long as you don't kill it with bureaucracy its an effective business model.
Can this approach be applied to engineering problems? They do tend to be a bit serious though and need project plans and costs and budgets and risk management and the like - which all sound very bureaucratic in the extreme. But, is there no way some of the more fluid principles could be applied without the project running over time and budget - wait - that's what large projects tend to do anyway even with all the bureaucracy!
I have just been involved in a large tender which carved up the engineering disciplines each being bid separately. It was evident that the difficulties of breaking up a system for tighter control led to a very restricted set of responses being asked for. Whether this is what was intended or not I'm not sure - it will certainly make marking the scripts easier - but will you be able to bring all the elements together again to form the fluid project team environments? Maybe there is some more bureaucracy we can call upon to help with that though ;)
Anyway - onward and upward.....
Sounds like a plausible approach to running a project or setting up contracting arrangements for a large project. Can you do this? It runs against the ethos of a systems approach and the systems engineering practice.
Businesses - which are effectively large systems of systems - these days are floundering towards more flat-open type management structures. This engenders emergent control within the workforce and more fluid problem solving as teams can form quickly and then disperse. Sounds agile - as long as you don't kill it with bureaucracy its an effective business model.
Can this approach be applied to engineering problems? They do tend to be a bit serious though and need project plans and costs and budgets and risk management and the like - which all sound very bureaucratic in the extreme. But, is there no way some of the more fluid principles could be applied without the project running over time and budget - wait - that's what large projects tend to do anyway even with all the bureaucracy!
I have just been involved in a large tender which carved up the engineering disciplines each being bid separately. It was evident that the difficulties of breaking up a system for tighter control led to a very restricted set of responses being asked for. Whether this is what was intended or not I'm not sure - it will certainly make marking the scripts easier - but will you be able to bring all the elements together again to form the fluid project team environments? Maybe there is some more bureaucracy we can call upon to help with that though ;)
Anyway - onward and upward.....
Saturday, 15 March 2014
Sprinting to the finish.
Back on track a bit more this post.
Just basically had to ditch a load of old software development processes - mainly because of the growth in number of documents and variations on what to do for different computing environments was out of control. Out of control to the point where it was difficult for new entrants into the document set to understand where to start. Best option was to just start again!
Things have moved on as well - as noted in previous posts - agile developments are the current flavour. To be honest this is the approach most people take to software development too - apart from some very expensive military type developments or safety critical applications that is where you may just want to be a bit more rigorous! But for general use most people just want to get on and start coding and an agile process lets you do this in a sort of controlled environment.
This is also the problem faced by engineering projects who's aim is not code development but rather to solve some engineering problem, explosion effects, fire impacts, evacuation implications etc. The problem is most of the time getting to the answer takes a bit of coding - not everything can be worked out by pencil and paper these days. So what are the options? Do some structured programming design following software engineering standards or jump onto something like Excel and start bashing away! Well you know the answer to that one don't you. Plus add a few Macros and Bob's your aunt you have created the monster. An answer to the engineering question pops out, you write the report, and 'file' the code.
And who can blame someone wanting to do that - we are generally paid for getting the answer not for building some shiny new software code. So, the trick is to integrate a development lifecycle into this very results delivery focussed environment. Enter the agile computing frameworks - using some of the techniques from previous posts like Just Good Enough, and Test Driven Design around project timescale based Sprint's - a level of software quality assurance rigour can be injected into the delivery without the 'developer' actually realising!
How do you do this ..... more later.
Just basically had to ditch a load of old software development processes - mainly because of the growth in number of documents and variations on what to do for different computing environments was out of control. Out of control to the point where it was difficult for new entrants into the document set to understand where to start. Best option was to just start again!
Things have moved on as well - as noted in previous posts - agile developments are the current flavour. To be honest this is the approach most people take to software development too - apart from some very expensive military type developments or safety critical applications that is where you may just want to be a bit more rigorous! But for general use most people just want to get on and start coding and an agile process lets you do this in a sort of controlled environment.
This is also the problem faced by engineering projects who's aim is not code development but rather to solve some engineering problem, explosion effects, fire impacts, evacuation implications etc. The problem is most of the time getting to the answer takes a bit of coding - not everything can be worked out by pencil and paper these days. So what are the options? Do some structured programming design following software engineering standards or jump onto something like Excel and start bashing away! Well you know the answer to that one don't you. Plus add a few Macros and Bob's your aunt you have created the monster. An answer to the engineering question pops out, you write the report, and 'file' the code.
And who can blame someone wanting to do that - we are generally paid for getting the answer not for building some shiny new software code. So, the trick is to integrate a development lifecycle into this very results delivery focussed environment. Enter the agile computing frameworks - using some of the techniques from previous posts like Just Good Enough, and Test Driven Design around project timescale based Sprint's - a level of software quality assurance rigour can be injected into the delivery without the 'developer' actually realising!
How do you do this ..... more later.
Wednesday, 12 February 2014
Asset Management
All in all a bit of a confusing subject area. But wait, why am I on this trail at all? Thought this blog was about computing revival?
Well - I have wandered into this through the work I did last year which had a focus on data and analytics around civil assets. Now the challenge is to expand this experience to other asset classes. I have been scooping on the subject for quite a while now - check the following link http://www.scoop.it/t/asset-management-engineering - which illustrates what a mish-mash of a topic this is.
What I am talking about here is not the financial kind of asset management but more of the engineering version and of course the links to software and data developments. Hence the interest!
An ISO standard (ISO 55000) has just appeared on the streets which immediately has created a rush to be certified. Not entirely sure why though as the standard is all about improving performance not ticking the box of certification. Can you have the box ticket but not be efficient? I would think so!
Hopefully this avenue will lead to Big Data nirvana or analytics heaven or something similar?
Onward and upward on the revival journey......
Subscribe to:
Posts (Atom)