Software application development
This blog is intended to provoke discussion and exchange between like minded software application developers, engineers, architects, project managers - and keen hobbyists too.
Tuesday 31 July 2007, 11:27 AM
Community Spirit
I often get asked about the relative worth of developer networks, user groups and professional certification. Are they a good idea? Well, the short answer is almost certainly yes isn’t it? But how much value do they add to your career?
Personally, I feel the greatest benefit they offer is ‘community’ i.e. the opportunity to network with peers and share ideas, opinions on emerging technologies – you know the sort of thing.
I’ve lost count of the amount of times I have stepped out of technical presentations at developer symposiums and asked the person next to me whether they got any value out of the content of the session – they almost always say, “nah, I didn’t learn much from that.” When I ask them again at the end of the week what they enjoyed most, they typically cite the chance to have networked with some likeminded individuals and chew the fat. This is the channel that developer networks and user groups should be opening up.
So whether it’s the MSDN, IBM Rational’s developerWorks, Sybase’s ISUG or even professional bodies such as the UK’s Institution of Analysts and Programmers – the key is ‘community’ as far as I see it. Not just local too OK? Let’s make it global and keep the ideas bouncing around the globe.
Friday 27 July 2007, 9:05 AM
Building with bugs
I heard an argument at a techie press conference recently that put forward what I considered to be a good argument for releasing a software build with known bugs on board. The code guru in question reasoned that there was a point at which, even with bugs in place, the time it would take to re-engineer the solution did not warrant a feasible return on the initial investment in the project. So if the software worked (even at 75% effectiveness) then why not roll it out?
Fair enough right? I'm sure we can all think of a large software company or two that does this.
Well, take it one step further. Over coffee afterwards – or it could have beer, I don't remember. I heard another sagacious Java developer tell me about how she left some bugs in her code as a matter of comparatively little concern. This was in order to, as she put it, 'ensure a little job security'. As a contractor, she wanted to know that the customer would be coming back for more. So if the customer asks for something during the requirements gathering process that the programmers know will slow things down, open up security loopholes or just generally cause 'clunky' operation – then give it to them. That way they have to come back for more.
I don't think this is an overly cynical view of the industry. But I do think it's realistic. Don't you?
Wednesday 25 July 2007, 1:19 PM
The core role of application lifecycle management in software development
Do you want to know what really gets most of the software engineers I speak to fired up and ready to spit blood? You guessed it, well, hopefully… they always complain that their team leader or manager is a clueless timewaster that lets project skew slide into the team development environment from day one and makes everyone’s life more difficult and less productive as a result.
But we all complain about our bosses don’t we?
Well, yes – but hell hath no fury like a developer’s wrath when he or she is being told what to do when they know that the project needs a greater degree of control and management. The answer? Application Lifecycle Management (ALM) tools are surely a good option aren’t they?
Of course, in practice, ALM is very seldom adhered to in the commercial world. Due to time-constraints and lack of funding, most customers choose not to incorporate a software development plan that would result in a solid product. Instead, quite frequently, a buggy prototype becomes the finished product. As a result, the customer ends up spending more time and money on software maintenance, fixing bugs, enhancements and redeployments. All of which cost more than they would have done had the IT function followed good software engineering processes initially.
Do you agree? Even better – do you disagree? Please share your thoughts.
