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.
Friday 28 March 2008, 12:04 PM
Symposium survivor
With some of the bigger software conference and events just around the corner many of us are braced for a week or two of technical briefings, keynotes and – wait for it – ‘birds of a feather sessions’. So whether you are headed for JavaOne, IBM’s Rational User Conference, Microsoft’s PDC, Adobe’s MAX or Red Hat’s Boston shindig I thought a quick user-guide might be in order and possibly generate some discussion among those of you who delight in ‘pressing the flesh’ at these get togethers.
So, here’s my top 10 guide to being a symposium survivor:
1 – GO EARLY: Avoid the registration queues, tour the facility and find out where you need to be and when you need to be there, sleep off your jet lag, take some pictures and generally get yourself together. A lot of these things start on a Sunday with pre-conference sessions, so arrive on the Saturday if you can.
2 – DON’T TAKE A LAPTOP BAG: Obvious I know, but true. You know you’re going to be given a bag, a couple of extra T-shirts, pens, paper and a water bottle. So don’t bother packing them!
'
3 – PLAN WITH MILITARY PRECISION: Get your conference guide and form an attack plan to underpin your personal schedule. Don’t just sit in sessions, go and meet some of the people you know you ought to meet. Accommodate for some time touring the cheesy exhibition centre stands.
4 - WHEREFORE ART THOU Wi-Fi?: Work out the best areas for WiFi coverage in the exhibition centre. Forget it in the keynote, there’s always a bunch of jokers setting up peer-to-peer networks and the whole thing goes into meltdown. If all else fails, take a tip from a journalist – go and sit outside the press room. They always make sure the press has WiFi so they can file their stories.
5 – STOCK UP ON SODA: Avoid expensive room service charges by taking as many extra bottles of soda, fizzy pop, water and choccy bars as your laptop bag can handle.
6 – KEYNOTE CALAMITY: Don’t miss day two and day three keynotes. They are typically better and more in depth than the “hello I’m the CEO and we’re all jolly glad you’re here” backslapping on day one.
7 – DEAR DIARY: Write up your show notes as you go along (it’s so much easier), that way when your team leader or project manager asks you to justify the expense of sending you away next year he or she is super happy as they already have a tidy little report to refer to.
8 – MINGLE WITH YOUR PEERS: Even if you are not the most naturally gregarious person try and chat to some fellow developers, DBAs or other software engineers. Find out about the different tools, techniques and workflow methods they are using. Who knows, you might even be able to find out whether you are being underpaid!
9 – SLEEP: It’s all too easy to go crazy working and partying over the first couple of days, take it easy and pace yourself.
10 – STAY LATE: If you’ve gone all the way to Vegas, Boston, LA, Barcelona, Amsterdam or San Salvador for a conference then chill out afterwards, take a dip in the pool, walk around the city, eat a hamburger – whatever, feel like you’ve walked around the block at least.
… and finally – don’t believe any of that “what happens in Vegas stays in Vegas” rubbish they spin you with (or Orlando or Barcelona etc…) – I went to a database conference four years ago and chased the pretty Java developer I had ever seen… and now she’s my wife!
Tuesday 25 March 2008, 9:38 AM
Apple Crumble Grumble
OK I know; Apple doesn't get a whole lot wrong does it? (Although I drafted this blog before seeing the lead story “Firefox chief fumes over Apple Safari update” on ZDNET this morning.) So it's sometimes tough to have a decent grumble. Speaking as an owner of a pair of Mac laptops and a nice shiny iPod I'm hardly best placed to start venting my spleen, but I think I have grounds here…
First, there was the incident of my browser imploding on my old PowerBook G4. OK, so I'm only running Panther and the new Safari upgrade is for Tiger upwards. So why did the software updater let me install and then decide to send all copies of Safari down a spiralling staircase of thermonuclear destruction?
Software updates come at you so often with Apple that sometimes it becomes a case of 'click to update' without giving it too much thought. Thinking about it more closely, it's usually just an upgrade to iTunes so they can sell me more "stuff" to download. Note to self for more caution in future - Firefox it is from now on then.
Then, after doing some digging around in the FAQ department of the online Safari support pages I noticed that there was a glaring lack of 'mobile development' info to be had. As I rifled through the reams of pages on best practices for development I thought, hang on – they have to be kidding, no web for mobile?
This was because I was already too far in – Apple appears to keep its 'development for iPhone' section separate to its web development section. I think this is a strange move from a strategic point of view based on the consensus from the rest of the industry. Mobile device access is a natural extension of all development, web or otherwise – isn't it?
Thinking about this little rant, I did speak to Apple's VP of developer relations Ron Okamoto a couple of years back. He's a lovely chap for sure, but our chat was all 'big picture' stuff and I wasn't able to write up a Q&A from it. Does Apple invite us developer-focused journalists to the Apple Developer Connection? They do not. Go figure.
Wednesday 19 March 2008, 9:54 AM
Do developers need fast typing skills?
I kind of get the feeling I'm going to get some flack for this - but as a matter of comparatively small importance, it does seem to have reared its head a few times. The question of speedy typing skills among developers seems to be a sticking point for some.
On the one hand I heard from a .NET developer pal of mine who types relatively slowly and tells me that this is because it's not a core developer skill. The ability to think fast, stay focused and keep sharply attuned to the code is more important, he says.
On the other hand, we recently had a talkback posted here at ZDNET about the fundamental importance of being able to employ "ten finger input" in programming work.
Also, if you read any of the blogs I posted from VMWorld Europe, you may remember me describing a story where a programmer had had to type physically faster than thought possible to hard code (or just perform an emergency fix) for an operation during a keynote demo that had gone wrong.
Yet again on the other hand I speak to people who are more involved with systems analysis, architectural planning and face-to-face customer requirements analysis – and this type of work, they say, means that they are naturally less speedy across the keyboard.
So which is it? A bit of both maybe – I know, I know… "It depends," right?
'
Here's some of the feedback I got when I asked around:
"Well I suppose it has something to do with being in command of the tools of the trade. It's not great to know that someone whose job it is to use the PC all day can't use the interface (keyboard) properly. What else can't they do properly? Someone who types slowly but claims to think fast must be a very frustrated programmer." Martin Clark, Enable Development, London, UK.
"Speaking as someone with mediocre typing skills, I think it depends. Some shops might require quantity and others quality - and some a combination of both. In my own world, fast typing isn't required, I'm thinking more on the fly, so when I compose emails, right some test code, log case notes, write up bug reports, I need to collect my thoughts and focus on the task at hand, all while multitasking. Because of this, fast typing wouldn't be of any advantage as my main skill is problem diagnosis. I'd think as a developer - from the people I work with - they're going to be a mixed bunch. Some are fast typers, others slower. It seems the fast typers are those developing new code - maybe because they've always been coders. Others who are slower seem to be of the ‘sustaining’ engineering type - they're testing more then typing, looking for bugs, thinking actually. When they're ready to code the fix, the amount of code is usually ‘light’ so the speed of typing is no big deal." Paul Vero, Sybase, Denver, Colorado.
"I spent 18 years or so as a software developer and have now been freelance writing for about 15 years... and I'm still a two finger typist – and a bad two finger typist at that! My philosophy has always been: there's no point for me being able to type faster than I can think!!! In fact, I have watched software developers – who have developed fast keyboard typing skills which are the equivalent of the old American West gunslingers – who are too quick off the mark and create serious problems for themselves because they type before thinking – sometimes with disastrous results! For me, at least, slow and steady wins the race!" Tony Stevenson, Hobart, Tasmania.
"I agree with the last reason... "it depends" on what aspect you do as a developer. If you are more of an architect or an analyst then typing is not a crucial skill. If you are a hard-code developer and code hack then you better be fast on the QWERTY! :-)" Chris Pollach, The Great White North Evangelist, Ottawa, Canada.
Monday 17 March 2008, 3:39 PM
Hitting the exponential software growth curve hard
Part and parcel of the software industry is the constant release of new versions of each vendor’s product. We look forward to version 1.0 throughout the beta process, we see 1.1 and 1.2 come along with enhancements and – if you believe the marketing – additional elements of functionality that did not fit into the original development cycle.
(Not because the company failed to think about them in the first place and had to rush them in for the update after user feedback of course.)
Then we get major re-releases and 2.0 comes along. Then 2.1 and so on – nothing new so far I know, bear with me please…
What the vendors sometimes don’t talk about with any specificity is the amount of code growth that goes on between the different phases of the application’s development. Is the same amount of growth going on between 1.1 and 1.2 – and does moving from version 1.0 to 2.0 represent the same as level of code update (and functionality) as the jump from 4.0 to 5.0?
'
The reason I pose these posers is that I’ve been getting used to working with QuarkXPress 7.1 – my page layout designer on the other hand is using 6.0 and the thing is that the there has been so much change between the versions that we can’t simply share files between each other. I can read his files, but I have to export backwards (to the previous version) during my saves.
(NB for technical accuracy I recently had the chance to meet Quark CEO Ray Schiavone and he assured me this situation has been or is being fixed.)
So the discussion here is that we should look carefully at new release roll-outs and ask what kind of change (and how much of it) has gone on. Also, perhaps we should ask ourselves why the company behind the application has carried out such a big software upgrade. Were they too busy doing something else? Were they just pushing tired out goods into the market? Was there a genuine reason why they went back to the drawing board and performed so much re-engineering?
We can ask the same question of small changes of course – are they just being done for marketing purposes? Are they being done to create an impression among the customer base that they are using a constantly evolving product? Is the company about to host its annual user conference and they need a product to announce?
Or – just maybe we need better release notes?
Thursday 13 March 2008, 11:50 AM
The software optimisation misnomer
It’s not difficult (if you go looking) to read lots about software optimisation these days. Vendors in this space will reel off copious (and possibly spurious) reams of information at you to detail how their optimsation compiler can help take an application from one form to another – often to spawn variants for different devices in different form factors for different uses.
But sometimes (in mobile development for example) this process involves scaling an application back so that it can work with a more limited set of resources such as memory, processing power or screen size etc…
'
OK sure, optimisation comes from the word “optimal” – but there’s not very much optimality about scaling something back is there?
So shouldn’t these vendors be forced to call it “software reconfiguration” for greater clarity?
Software optimisation as a pure bred process should always be concerned with making the application’s runtime execute faster for the particular environment that it works within. Surely writing code without memory leaks with more efficient algorithms for an application that works like it is designed to is what should define optimisation.
After all – those sparkling wine producers (USA excepted) had to stop labelling their plonk with the word Champagne didn’t they?
Previous
