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
All things computing, software engineering and physics related! Now also including retirement stuff.
Tuesday, 6 May 2014
With a bit of luck I have just connected my tweets to my blog by 'programming' @IFTTT - will be well impressed if it works!
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......
Tuesday, 28 January 2014
2013 theme park ....
Just before January is out I thought I would do my annual appraisal - just to make sure the 'revival' is on track!
2013 has been a roller coaster year for me on a number of fronts - but just how is the revival going. Well 2013 has been a bit of a milestone on the revival path. I've realised I am not as far off-piste as I thought I was when I started reviving myself. In fact, some bits don't need reviving at all they are revived and operating quite well thank you very much. However, not the bits you normally associate with software engineering!
The one thing that the past year has brought home to me is the pace of change in the industry. Frantic! Managing a business critical project in this constantly changing environment has been an exciting challenge in 2013. It just so happened that I started off the year studying for a 'certificate in complexity' at the Santa Fe Institute. Just out of curiosity, interest, development, not quite sure which. I didn't quite realise how useful this was going to be in understanding some of the issues that went throughout the rest of the year. Its a fantastic course (and book), I have said it before but say it again, thoroughly recommended. Plus its offered free, or was this past year, it was so good though that I donated to the cause anyway!
So complexity, in all its guises, is cropping up everywhere from social networks through to 'big data' and was the No. 1 theme for 2013.
The revival had started off as a wish to get back into some form of programming again. I did have a foray into Fortran a couple of years ago which basically told me not much has changed. This past year though this trail has led to specification and assessment of big-systems architectures. What started of ass an analysis of a requirements set ended up as a full on programme of work to install an asset management system for a large corporate. So a bit of a detour from the original but its a journey that I am very glad I took as it has given me an insight into both process and capabilities at this corporate system level. Something that I would normally have avoided like the plague being a more 'signal processing' guy! Although I didn't have much to offer in the big-systems front, or 'solution architect' front as it is called, I found I did on the process and management side of things. Specifically requirements and 'selection' processes and the management and engagement of teams. If you can codify what it is you are doing then you are half way to being able to explain it and indeed get others engaged in what you are doing.
So, codifying complexity in a process, a necessity to be able to focus development efforts and the team, is the No. 2 theme for 2013.
During this project there were two points throughout the year where there was opportunities to 'get on and do something'. Elements of the system could have been designed and built by the internal business software teams. That is rather than paying someone external to do it of course! However, the governance processes in the business essentially delayed activities to a point where it was then no longer viable to build internally anymore. Don't ask how this happened, safe to say that everyone was pushing for it to happen but the 'engine' couldn't turn fast enough. Which is a real shame, not to mention a costly impact on the business. The not-so-hilarious thing is that the external (big)company who was then employed to do the work suffered exactly the same issue! Blind leading the blind comes to mind. Its endemic - governance processes don't seem to have kept up with either the business environment or the agile working nature needed to service this modern climate.
So agility, not just in software development but also in decision making is the No. 3 theme for 2013.
A final thought relates to systems management - there are 'architects' at all points of the compass with conflicting advice - all very well though through of course. The trick however, is to know what the art of the possible is, and this requires clear business led management. Not IT, not any 'architecture' and not any expert system! It's engaging brain and putting in effort to understand exactly what the business needs and can handle in terms of change.
So, taking back technical management control of complex projects, not project management or cost management is the No. 4 theme for 2013.
2013 has been a roller coaster year for me on a number of fronts - but just how is the revival going. Well 2013 has been a bit of a milestone on the revival path. I've realised I am not as far off-piste as I thought I was when I started reviving myself. In fact, some bits don't need reviving at all they are revived and operating quite well thank you very much. However, not the bits you normally associate with software engineering!
The one thing that the past year has brought home to me is the pace of change in the industry. Frantic! Managing a business critical project in this constantly changing environment has been an exciting challenge in 2013. It just so happened that I started off the year studying for a 'certificate in complexity' at the Santa Fe Institute. Just out of curiosity, interest, development, not quite sure which. I didn't quite realise how useful this was going to be in understanding some of the issues that went throughout the rest of the year. Its a fantastic course (and book), I have said it before but say it again, thoroughly recommended. Plus its offered free, or was this past year, it was so good though that I donated to the cause anyway!
So complexity, in all its guises, is cropping up everywhere from social networks through to 'big data' and was the No. 1 theme for 2013.
The revival had started off as a wish to get back into some form of programming again. I did have a foray into Fortran a couple of years ago which basically told me not much has changed. This past year though this trail has led to specification and assessment of big-systems architectures. What started of ass an analysis of a requirements set ended up as a full on programme of work to install an asset management system for a large corporate. So a bit of a detour from the original but its a journey that I am very glad I took as it has given me an insight into both process and capabilities at this corporate system level. Something that I would normally have avoided like the plague being a more 'signal processing' guy! Although I didn't have much to offer in the big-systems front, or 'solution architect' front as it is called, I found I did on the process and management side of things. Specifically requirements and 'selection' processes and the management and engagement of teams. If you can codify what it is you are doing then you are half way to being able to explain it and indeed get others engaged in what you are doing.
So, codifying complexity in a process, a necessity to be able to focus development efforts and the team, is the No. 2 theme for 2013.
During this project there were two points throughout the year where there was opportunities to 'get on and do something'. Elements of the system could have been designed and built by the internal business software teams. That is rather than paying someone external to do it of course! However, the governance processes in the business essentially delayed activities to a point where it was then no longer viable to build internally anymore. Don't ask how this happened, safe to say that everyone was pushing for it to happen but the 'engine' couldn't turn fast enough. Which is a real shame, not to mention a costly impact on the business. The not-so-hilarious thing is that the external (big)company who was then employed to do the work suffered exactly the same issue! Blind leading the blind comes to mind. Its endemic - governance processes don't seem to have kept up with either the business environment or the agile working nature needed to service this modern climate.
So agility, not just in software development but also in decision making is the No. 3 theme for 2013.
A final thought relates to systems management - there are 'architects' at all points of the compass with conflicting advice - all very well though through of course. The trick however, is to know what the art of the possible is, and this requires clear business led management. Not IT, not any 'architecture' and not any expert system! It's engaging brain and putting in effort to understand exactly what the business needs and can handle in terms of change.
So, taking back technical management control of complex projects, not project management or cost management is the No. 4 theme for 2013.
Here's to 2014 then!
Tuesday, 3 December 2013
Good to go
When is good enough - good enough?
When its Just Barely Good Enough, of course!
JBGE - I find - is the term used on agile projects to make sure you don't 'guild the lily' (GTL). Once you have something that can reasonably be built and tested the plan is to go for it in a 'sprint' development to get early sight and feedback on what you are building. Helps developers, helps users, helps produce a more targeted end product. You may have to go round the loop a few times refining and changing - but that's the nature of the beast anyway in the software development arena.
An excellent view of how this fits into agile developments can be found on the following link
www.agilemodeling.com
The issue comes when you try and introduce these techniques into organisations who are steeped in the more tradition waterfall approach to software development. Lets get the requirements - all of them - can't be doing with a bit of uncertainty, therein lies risk - write them all down then tick them all off as we grind through the design and development cycle. Trouble with this approach is - and don't get me wrong it does have its uses in certain arenas where you need to have full control and visibility - in a fast moving business environment, you will be overtaken by the opposition if you are not fleet of foot. If you are not careful the waterfall will simply be a cliff edge!
What the more agile approach provides are mechanisms for accelerating a project other than simply chucking bodies at it. You can shorten the 'sprint' - build intermediate releases, for example - which can help accelerate testing and user acceptance. You can re-evaluate what is JBGE for the development - does it really need to be all shiny and new?
Onward and upward ;)
When its Just Barely Good Enough, of course!
JBGE - I find - is the term used on agile projects to make sure you don't 'guild the lily' (GTL). Once you have something that can reasonably be built and tested the plan is to go for it in a 'sprint' development to get early sight and feedback on what you are building. Helps developers, helps users, helps produce a more targeted end product. You may have to go round the loop a few times refining and changing - but that's the nature of the beast anyway in the software development arena.
An excellent view of how this fits into agile developments can be found on the following link
www.agilemodeling.com
The issue comes when you try and introduce these techniques into organisations who are steeped in the more tradition waterfall approach to software development. Lets get the requirements - all of them - can't be doing with a bit of uncertainty, therein lies risk - write them all down then tick them all off as we grind through the design and development cycle. Trouble with this approach is - and don't get me wrong it does have its uses in certain arenas where you need to have full control and visibility - in a fast moving business environment, you will be overtaken by the opposition if you are not fleet of foot. If you are not careful the waterfall will simply be a cliff edge!
What the more agile approach provides are mechanisms for accelerating a project other than simply chucking bodies at it. You can shorten the 'sprint' - build intermediate releases, for example - which can help accelerate testing and user acceptance. You can re-evaluate what is JBGE for the development - does it really need to be all shiny and new?
Of course you need to make sure that what is produced is fit for purpose and doesn't fall into the NJCP category (Not Just Crap Programming).
Onward and upward ;)
Subscribe to:
Posts (Atom)