mj writes:
- are university degrees worth the bother?
- are universities correctly servicing the IT industry (and specifically the games dev market) with skills, knowledge, toolsets?
- why have IT graduates decreased from 1900 in 2004 to 600 in 2007?
- are we seeing a knock on effect from technology failures in the province, e.g. Nortel, Seagate
- with the improvement of toolsets, a lone hobbyist can create ‘flickr’ or ‘facebook’. Is this relevant?
- will we see an upsurge again with demand from Citigroup, Aepona, ATG etc?
Degrees are only useful to get you your first job. If you’ve got your first IT job without a degree, then you don’t need one. After that, it should be possible to achieve what you want with a bit of hard work. At least that’s what I’ve found.
I don’t think universities can be blamed (too much) for not servicing the industry, just given the nature of each. A degree takes 3-4 years to complete, and the content of it is usually created before the degree starts. 3-4 years is a long time in computer terms: 2-3 generations of processor speeds, anywhere from 1-4 major releases of software/language/OS. Really, the best a degree can hope to do is teach good guiding principles and a reasonably relevant language (and yes, I do think Java is probably the best language to learn at Uni).
As a recruiting manager, I’ve found that IT graduates are decreasing for two reasons: the pay is not what it used to be, and you can’t become a millionaire overnight any more. Ironic, given that starting pay has now gone up and some 2.0 companies *are* becoming overnight millionaires. This same trend in hiring is across the world, not just Northern Ireland.
Technology failures: maybe - however, both of those companies are large multi-nationals who opened an outsourced hardware plant in the province. To jump ahead to your last bullet point, these new companies are doing the same but for software/services, which (arguably) has a lower capital investment and, given the more dynamic nature of it, a higher chance of success. I think Northern Ireland really needs some more home-grown successes, and preferably ones that aren’t as staid as Lagan.
Toolsets: it’s semi-relevant. See my earlier post.
Software is not about code. It is about your company’s relationships. I have started seen companies with innovative products that use cutting edge technologies fail, simply because they didn’t understand their relationship with their customers, or didn’t understand it in time. Likewise, companies with demonstrably crap software (or even vaporware) thrive because they know who and what pays their bills.
This is both good news and bad news. Given how easy it is today to create any kind of app (and it’s getting easier, with Apple, Amazon, Google and Yahoo! all pushing open source frameworks and cheap services to lower the barrier of entry) the bad news is that your cash cow is easily copied by a Small Team with a tight focus. The good news is that if you are doing things right, it’s not about your software it’s about your relationships. So, once Small Team has created a faster, more scaleable, prettier version of your app but fails to get anywhere because you have your market sewn up, why not just buy them instead of spending money trying to compete on features? That works for Small Team too, because they get to continue to focus on what they do best (innovating) while someone else handles the money.
This approach seems to work well for non-software companies. I’ve seen software companies acquired by more “brick-and-mortar” enterprises, simply because said enterprise needed the technology to compete and didn’t want their competitors to be able to buy it.
I’ve had my MBP since November. Thanks to Moore’s Law, there is now a faster and shinier version available, which means that the price for a used 2.4Ghz MacBook Pro with the same specs as mine has dropped to about $2000 (according to eBay).
This is actually good news for me. I was considering selling the laptop so I could help fund various other things I needed to do. By the time I’m able to sell, the price will be low enough that it won’t be worth my while 
I just recently finished taking a course as a rescue diver. In it, I learned techniques for dealing with a panicked diver on the surface and underwater, dealing with unconscious divers, rescue breathing, CPR and many other things I’d never done before.
The instructor pointed out that I kept apologizing every time I did something wrongly. She pointed out that I’d never done it before, and that I was on the course to learn how to do it. This seemed obvious, as soon as she mentioned it, but it got me to thinking about why I was apologizing.
There’s an old saying about not being able to teach an old dog new tricks. People apply this to themselves as they get older as a way to say they can’t learn anything new.
The conclusion I reached is that I was apologizing for being incompetent. I’m used to being good at the things I do: whether it’s professionally or personally, after 31 years on the planet I’ve become reasonably competent at a whole bunch of things. Trying to learn new skills makes me incompetent again, and there’s a fear of failure that goes with that. It’s a lot easier to deal with now that I’ve acknowledged it - this fear is purely a fear of appearing foolish or incompetent.
Next time I’m learning something new, I just need to acknowledge that it’s OK to be incompetent
I was out on a boat trip just off the coast when we spotted some dolphins. The adults came over by the boat and led us away from where the babies were feeding, which of course made for some great photos. Here are a few - apologies for small file size, but uploading from here is a pain.
From mj:
They break out the infrastructure and make it P2P. This could shift the responsibility for uptime to others and allow them to host their own options for advertising or value-added services. Maybe even license the software out so there are a bazillion twitter servers out there. This would be the method by which Twitter could sneak up and murder Instant Messaging in it’s sleep. I tweeted recently that Twitter was not Broadcast IM. But, of course, it is.
Reminds me a bit of Zed’s UTU project.
To speak to some of the other points that mj makes (and bear in mind I’m only a recent Twitter user), I think that Twitter could monetise easily enough. There is definitely a stigma against running adverts on your website - I know I don’t do it on any of the sites that I run, even though I know I would make some money. But consider the sorts of users who use Twitter a lot - they are the same sorts of people who are happy to pay $10-$25 for an app to allow them to use Twitter more easily.
Twitter haven’t charged anything for their API or the right to use their service as a platform for making money, which no doubt has earned them a lot of kudos and is probably another reason for the large uptake. I’m certain that a portion of those people who use their service every day, n times a day, would be willing to pay that $10-$25 for improved services. I think mj is right with things like being able to add pictures, having URLs automatically “tinied”, being able to make their own look and feel to posts and so forth. Would it make enough?
I don’t know how many users Twitter has, but I’m willing to be that all of the active ones fall squarely in “Early Adopter” (if you subscribe to the Crossing the Chasm metaphor). In using the Twitter site, I’ve been a bit underwhelmed by it’s functionality. Keep the free service, improve it gradually, but innovate like crazy in a pay-for service.
One possible ego-stroking mechanism. Make it such that you must be on the pay-for service if you have more than 100 people following you.
None of them are particularly spectacular, but I felt I should let people know a bit about what I’ve been working on. I’m also working on a website for a Cyprus property investment company, which should be done in the next couple of weeks.
From Cimota.
cat ~/.zshist | awk '{a[$1]++} END {for(i in a)print a[i] ” ” i}’ | sort -rn | head -10
2870 ls
2444 cd
659 vi
348 rm
254 svn
232 ssh
206 telnet
182 whois
180 egrep
179 sudo
Here’s the scenario: you’re writing a green field web application. This application will be used to power more than one e-commerce site, which means that it must be easily tailored. You can use any toolset you like, and the requirements are fairly standard (e.g. exporting data to CSV, modern UI, payment gateway, etc.). What do you choose?
- Off-the-shelf e-commerce engine
- Open-source e-commerce engine
- Build your own
So, it seems you’ve got three options (anyone think of a 4th?). Of course within each of these options there are any number of competing solutions, especially in “build your own”, where you could potentially use any language, web server, etc.
I think with any software developer, the preference is to build one’s own. That way you get ultimate flexibility and intimate understanding of the code, which makes it easier to expand and customise. The downside is that you have more work up-front in order to get running.
Off-the-shelf (i.e. commercial) software tends to have a lot of features that your accountant and fulfillment department would like, and often gives you the ability to customise using one of a few popular languages or their own pseudo-language. The real advantage is that you can have a store quickly, or so you might think. Often, shoe-horning your data into their proprietary and closed-source format makes this option longer and more expensive than building it yourself.
All of which leaves open-source engines. You can be up and running quickly (like with commercial apps) but you have access to the source code if you decide you need to change things the way you want them. Potential downsides are lack of support and lack of particular features you might need (e.g. a particular payment gateway).
So, which would you choose?
1. Prove it works
write the simplest code possible to show one thing working end-to-end
This can be as horrible and hackish as needed. I regularly hardcode things like URLs, integers, strings, file names/paths: whatever is needed just to show that the idea works. E.g. for Rickshaw, I started off by always sending a file called rickshaw.png, which just got removed and replaced by a URL - the URL in the e-mail was hardcoded to be a reference to http://localhost/~aidan/rickshaw.png, and I happened to have the file in that directory. The whole workflow appeared to work, even though none of the upload magic was there. I proved out two concepts though:
- that attachments could be manipulated after sending
- that the resulting e-mail still made sense
2. Add to it
write the next most important bit simply, then test it all
This can be harder than you think. Not the writing, but choosing what bit is the next most important. For me, I wanted to have that file be written dynamically. The important thing is to keep it small - do it, test it and be happy with it. Some things lend themselves to automated testing: some don’t. I’m a fan of test-driven development, but I don’t get hung up on ensuring coverage - look at Microsoft Windows Vista: excellent automated test coverage, crappy user experience. Test manually where it makes sense, and automatically where needed.
3. Repeat step 2
You go from your tasks being “remove hardcoded URL and replace with URL generation code” to “Add application icon” and “Build website to sell app”. One step at a time, doing the most important thing at any given time.
Rickshaw had no user interface for quite some time - it was just a plug-in that was copied from the command line. Eventually that was good enough that a UI for configuring it was the most important thing. Then a button that tested the configuration before using it. Then some code to install the plug-in. License keys. Usability enhancements. And so on.
None of this is new or original - it’s all common sense, especially if you’ve worked in an agile development team before. The great thing about working this way is you see results early on. I had a working prototype of Rickshaw which did “uploads” to localhost (using NSData writeToFile:atomically) within a week, and real uploads within three weeks. The downside is that you feel very close to finishing at an early stage.
If you consider the entirety of what’s needed to build an app as being 100% of the effort, I’d lay out the effort required for different parts as something like this:
- Hack to prove concept: 5%
- Prototype to prove hack: 15%
- Making prototype robust: 30%
- Getting it ready for users: 50%
Open source projects are one of the first three stages (corresponding roughly to ‘alpha’, ‘beta’ and ’stable’ projects). The last stage takes just as long as the first three, and it’s the reason why commercial Mac apps (in particular) are better than open source apps for Linux - as much time has been spent getting the application to work well for users as has been spent getting the application to work for the developers.
If you’re developing an app for any platform, ensuring you spend the time in that last stage is what will make your work stand out.