| CIO Blogs
IT Blog Awards |
Subscribe
RSS news feed
Add to Technorati FavoritesRecent Posts
- Wave! You are live and online!
- New Game Changers for the Internet; Opinions differ on value!
- Do Turkeys vote for Slow IT?
- The Internet of Things just got a little closer
- The Washington Template
- Secure ID – gets a work around with support from key vendors
- The Ideality of the Cloud
- Situational Software - The ‘Killer Application’ for Enterprise 2.0?
- Guest post on Sustainability by Colette Lewiner, Global Leader of Energy, Utilities & Chemicals, Capgemini
- Where the work should be put? Time for Phase 2 in the Off Shore debate
Navigate
Search the blog
Software Engineering
I'm hip, I'm cool, I'm agile (*)
Bombarded by a decade of self-proclaimed guru’s, evangelists and other romantic revolutionaries (including myself, just to set things straight) I think we got the message by now: agile development is in, waterfall development is out. At the risk of having our readers drop out of this blog-item– and I would not blame them – let’s summarise some of the original ideas. The understanding of the objectives, possibilities and risks around a solution grows during the lifetime of a project. This is why it is better to develop a system through small pieces, going through the entire lifecycle of specification, design, build and test. Combine this with small, multi-disciplinary teams and a frequent recalibration of priorities and direction, and you get better results with more commitment in the client organisation.
When well applied, it brings you right into the heart of both the organization and the problem space. Just like with a stew, quietly simmering on the gas. Frequently, you lift the lid to stir it all a bit and have a taste. Let’s see how the flavour evolves, if the herb mix needs to be adjusted. Maybe it is even time for a new ingredient. The resulting dish is exactly what you want and it radiates the love and carefulness that have gone into it.
Almost sounds like Slow Food, doesn’t it. Not the very first association that many people nowadays would have with agile development. And indeed, practice often turns out very differently. The agile principles then seem to become an ordinary alibi for wheezy ADHD behaviour, not having to think and misplaced pragmatism. Just Do It: everybody is working hard, but the foundation is missing and the project persists in following a jittery, unpredictable path from iteration to iteration.
The Best Code is No Code - 7 ways to avoid errors by programming less
Just recently the SANS institute and MITRE published a Top 25 list of most dangerous programming errors that lead to cyber crime and other problems with websites. Experts from more than 30 organisations – including software companies, universities and the US government – collaborated in creating the list. One of the findings is that just a small number of errors cause the bulk of problems around nothing less than 1.5 million websites. Problems vary between sites simply ‘going down’ to theft of personal and financial information and complete computers being taken over from remote locations.
The list is well worth to read – it’s written in an unexpected, humorous style – and it is mandatory, educational stuff to software engineers and cyber criminals the like. However, the list notoriously misses the biggest cause for critical errors in software: simply too much software is still being coded. It shows that IT yet is a painfully immature profession. The practitioners stubbornly persist in creating their own problems and then – with great aplomb – come up with lists, articles, methodologies and books to solve them. It’s like turning all the taps on in the house and then proudly pulling out the newest, moist-absorbing mop. With more software being hand-coded, the risk of errors increases. And although many programmers may share a nostalgic sentiment on producing their code line by line, it does not serve efficiency or security.
The best way to avoid dangerous coding errors is to code less. Here are 7 ways to achieve that:
Testing Times from the Credit Crunch
I had a task flag to take a look at the proceedings from the annual International Conference for Software Process Improvement, ICSPI 2008, but on visiting their site I was pretty amazed to find this message. Due to severe cuts in education and travel budgets across most organizations, the International Conference on Software Process Improvement (ICSPI) 2008, which was scheduled to take place October 20 th -24th , is regretfully being postponed until October, 2009. Yup a casualty of the credit crunch it would seem.
Okay maybe this isn’t one of the biggest events around, but it has been a good ‘working’ event by the people involved in the topic for the people who are involved in the topic, but maybe that’s been its downfall, no big names and publicity just the kind of good feedback and discussions we all feel the need for from time to time. The major reason I was interested was in the ‘how’ software development processes can be improved. It’s part of my own feelings that development tools are improving, but on the other side of the fence smaller, faster, is likely to be the way increasingly, and this, particularly in ‘tough times’ is likely to put pressure on time which all to often means quality suffers.
So if the credit crunch is changing the projects what about the testing side? After all testing tools are expense, often expansive, and their use can be complex, all of which seems to be going in the opposite direction to the trend towards smaller simpler better defined projects where presumably the risks are also better clarified. Sure enough there are some companies out there who have recognised the opportunity with single user testing suites.
Effortlessly Complex
I have to admit, at first glance I was pleasantly surprised. Somebody pointed me to a recent article of two professors at the New York university in which they argue that Java is an unsuitable language to learn how to program.
Instant recognition!
Java and me, we just don’t get along that well. All in all it’s just a nasty, posh little programming language. And far too complex, for that matter, like the evil twin sister of UML 2 (which itself deserves a Nobel prize for deliberately confusing people on a world-wide scale). Syntactically, Java has all it takes to guide a satellite to Mars or to control a nuclear plant. And then it is often being used to create yet another simple accounting application, insurance policy system, client management tool or user interface. It feels like cracking a walnut with a sledge hammer. Like someone in a tasteless, silver-coloured singlet is showing off muscles in the gym. A flashy display of power that almost begs to make errors and be unproductive.
And it has object-orientation built in too, a slightly overrated concept, if you ask me. Well, on the other hand, it is quite an achievement of the IT profession to create a structuring principle that fits so perfectly bad with the relational data model. And people keep on writing books about object-to-relational mappers. We violently force an apple through a sieve and are proud of the resulting pulp; who said IT doesn’t matter?
Ah yes, about that article.
Finally, somebody dared to speak out. I hoped. But I soon found out that the scientists are actually on the other side of the camp. From their perspective, Java is a light-headed, frivol tool which you use to quickly knock together some ad-hoc Internet applications. If programming becomes so easy and fun, then nobody needs to understand formal methods and complex algorithms any longer; this is the essence of their complaint. To put it even stronger: this way programmers become replaceable, because others – outsourcers for example, of all people – can do it too!
As an alternative, they recommend Ada, a nearly incomprehensible language which is rarely used to create programs. In that way, programming can again become the science it is truly supposed to be.
You’ve got to hand it to them: it’s definitely a landmark in staying away from reality.
SaaR or Software as a Revolution
Mark Benioff, the CEO of Salesforce.com states that he has the intention to ‘change the Software industry’, and many would agree he has made an interesting start in the Customer Relationship Management, or CRM, sector. However what caught my eye was the relatively low key announcement of the new capability that allows Salesforce.com customers to develop their own applications on the Salesforce.com servers, using the Salesforce.com Apex Platform toolset. After completion and I assume testing, the resulting applications will be delivered and managed by Salesforce.com on a Software as a Service, SaaS, basis.
Development Idol
For almost ten years now, I have been a jury member of the annual RAD (Rapid Application Design) Race. This is a nation-wide programming contest in the Benelux (here’s the link, a good opportunity to work a bit on your Dutch) in which teams of two developers have to create a working solution within 48 hours, using the tools set of their choice. A few years ago, the organizing committee decided to rename the contest to ‘Development Tools’, apparently to emphasise the importance of tools in productivity.
This could also be noted in the recaps of the races – published in a local IT magazine – that year after year focussed more on the features and peculiarities of each tool being used. The target audience of the magazine, software engineers, apparently just love to meander through the pro’s and cons of programming languages and development platforms. It’s an addiction, really. Just very recently, I witnessed yet another elaborate discussion unfold on e-mail, comparing JEE (Java Enterprise Edition) with .NET, trying to establish which platform was the most productive.
It just confirmed me again in what I already realised when I read the report of the most recent RAD / Development Tools Race: why writing piles of articles about the bells and whistles of tools where in-depth interviews with the winners and losers would have taught us so much more?
Rocket Science
Is there always something new to wish for? In some cases, you are inclined to think not. Take for example Charles Simonyi, an above average gifted programmer from Hungary who joined a modest start-up company in the beginning of the eighties that would later headquarter in Redmond. But not before working at Xerox Parc with IT legends legends such as Alan Kay and Robert Metcalfe on some, well, interesting projects (the first WYSIWIG text editor in the world, somebody had to come up with it). If you joined Microsoft before the PC existed and you sort of single-handedly created both Word and Excel, you may claim some street credibility in the IT profession.
Financially, you are probably doing quite well too: Simonyi is an active philanthropist, with an emphasis on supporting art and culture.
Clearly he saved a little for himself too, as he made headlines in the past two weeks as the tourist who paid 18 million Euros to fly with a Soyuz to the International Space Station. The crew had plenty of work to do there, so no doubt Simonyi had oceans of free time during his stay. There must have been some contemplative moments, Charles having a look through the porthole at Mother Earth, circling underneath.
Reached the absolute top in the profession. In addition, made a virtually impossible boys dream come true. And he might still be asking himself if there is a new daring challenge somewhere, waiting to be cracked.
Fortunately, it looks like Simonyi already has all the clues on where to search. In 2002, he left Microsoft to pursue with his own company the answer to the question that has been haunting the IT industry ever since the very first beginning:
why is it so terribly difficult to develop good software?