Buffini's Blog

How do people get their information? It occured to me recently that, while the internet is great and the ultimate resource for Life, The Universe and Everything, in general I prefer to get my information directly from other people.

Thinking about it, it seems to me that there could be a couple of possible reasons for this.

1. Laziness – When the situation calls for it I will go and search the BeJaysus out of something until I’m satisifed with the answers, so that doesn’t seem to be it..
2. Ease of access – there’s normally a better chance of getting information quickly from someone close by, particularly in a work context, but I will happily take my time and get specific items from specific people, and sometimes that can take a little time, so thats not it…
3. Contextual/Added information – whereby the information gleaned from a particular person will have added relevance due to situational experience, etc.. Closer to a winner here…
4. The personal touch – here we seem to have a winner. I like interacting with people. I’m a social beast, like most of the human race. I occasionally work from home and find the boredom to be stunning in the extreme, so I only do it when absolutely have to.

So it would seem that I like people. Todays instantly accessible information has given me direct access such as this, because in the past there wasn’t anywhere near as much generalised knowledge swirling around in both the aether and people’s head, so carefully lookup was needed to find information, meaning not as many did it.

The synopsis I draw from this (something other, much more clever people have figured out already ) is that the modern age with fingertip availability, social knowledge transfer, and the great swarm of data living in us all, is in fact yet another social enabler. People can interact even more now than ever before, and in new and interesting ways due to the magic of the tech and the evolution of society and societal memes.

Makes you happy to be knowledge foraging…

Interesting reading

1. Legacy software is essential software that cannot be changed at the speed which the user organisation requires

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