From a management perspective this is true. From a developer perspective this is largely false. The developer will know that there are often times when you can develop system updates, new architectures, etc.. at a speed that will largely satisfy most people. The problem arises with the users/market. The market will not be ready for the latest and greatest a company has to offer in the beginning, and frequently this will continue until a certain software maturity has been reached. The cost and risk factors also play large roles here. Spending, when weighed up, contrasted with all of the relevant factors and so on, will usually fall back to “If it ain’t broke….”. It frequently just isn’t cost/risk effective to update to the cutting edge, when the investment for the dull hammer has already been made and still works just fine.

2. Unless work is applied to counteract the appearance of legacy symptoms, any business-critical software is likely to become a legacy system sooner or later

Basically this statement boils down to two items: it can be maintained, or it can be evolved. Maintenance will involve fixing little bits and pieces, keeping things ticking over. Evolution will take the existing processes, tacit or otherwise, and create a newer, leaner, meaner and keener beast out of it. Its the football equivalent of keeping a team chugging along with the same players because they get along ok, and nothings reeeeeeally broken… whereas evolving the tem with new players, new trining methods, new coach, etc… will make it a world class competitor.Wrapping legacy systems, acquiring FOSS, modular development; all of these things are good and will, but its down to corporate mentality as well.. willingness to change and evolve will be core here..

3. Wrapping legacy software and it’s integration with newer software should be considered when replacement is too risky or too expensive

I’d agree and disagree here. Yes, wrapping should be considered if absolutely necessary, but NOT at the risk of compromising the system – from my point of view this would mean not wrapping if there is a reasonable justification for re-engineering the system/process/whatever, extracting all of the lessons learned from the current implementation. There should be some sort of bias in the judging system towards a new implementation, obviously backward compatible with the old junk, but this should nearly always be the best option. Preserving the old stuff for the sake of it or for penny pinching, etc, is just wrong.

4. In COTS-based projects the requirements are limited, shaped and conditioned to what the COTS vendors can offer

5. Component-based development provides value through cost efficiencies and trhough the emergent properties of the integrated applications

6. There are still limitations to the wide use of components, including issues of reliability, risk, trust and lack of support for the future evolution of the component

7. Successful open source acquisition and deployment requires tapping into other diverse sources for support and this requires a more diverse approach than when depending on a single supplier

8. Acquisition of open source software can be primarily motivated by a cost reduction strategy and not by the availability of the source code

9. Outsourcing beefits from a number of economic and technical efficiencies. However, this option may lead to a client’s loss of control over the software

10. Advances in methods and process capability of software organisations expand the types of software activities that can offshored

11. Instead of owning or licensing the software to run on your machines, you can rent time using it at some service provider

12. Software acquisition as a service (e.g. web services) requires adequate resolution of issues of responsibility, trust, risk and security

13. Software provision does not end with the selection of a source and the acquisition of the software and its documentation

14. Software acqusition consequences go beyond the immediate decision: they may have far-reaching impact

Image via Wikipedia

I got a set a couple of years ago from my girlfriend for Christmas, and at the time, because the bundled software wasn’t the may west, I wasn’t able to do a lot with it. Since then I’ve branched out a good bit into the wilds of open source code and custom hacker y and discovered LeJOS (lejos.sourceforge.net). At it’s core its a tiny JVM, based on (drum roll please) TinyVM . There are versions available for both the RCX, the older model that I’ve got, plus the NXT, the oh so wonderful beautiful shiny, fandiddlyastic new one that comes with aaaaaaalll sorts of goodies. There also other packages available in other languages, such as C#

What this gives you is the ability to write your own Java code to make the funny wee robots do damn near anything. The new version gives full access to the bluetooth commands (I think..) , so if you went with this OS, you’d be able to do fancy stuff like construct a motion detecting robot that looks like Johnny5 (God bless this woman, she is a LEGEND), that fires off lego rounds and chases people around the room. (I think I’m drooling on my keyboard…)

There’s also a handy wee Eclipse plugin for both the RCX and the NXT that will do all of the interfacing between the machine and the brick for you, meaning that all the programmer has to do is write the damn code.

I’ve gotten all of the underlying basics up and running on my home system, or I had before it presented me with a delightful BSOD. Luckily I run an Ubuntu dual boot, and all of the shiny bits run under that too so I can just shift over. Whenever I actually get around to creating something useful is a whole other story. See related articles for other fun.

Note: Google just handed me this lovely little snippet of Lego-like goodness. Oh the fun we could have…..