I'm at the QCon conference in London, one that I particularly value for its vendor-neutrality and strong content. Yesterday we heard from Robert Martin, founder of Object Mentor, on the subject of software craftmanship, or how to avoid bad code. One of Martin's points is that having code that works is not enough. He makes an analogy with a machine. It's not enough that your car works; when you open the bonnet you want to see good engineering, not a tangle of pipes, wires and belts that somehow hangs together.

Software is vulnerable to poor craftsmanship because code is often well hidden from customers and end-users. Still, the programmer knows whether they are putting together something that just about works, or crafting something excellent that will be understandable and maintainable long into the future.

Martin's talk turned out to be a practical one. There was nothing really new; but plenty to think about. Here are a few of his tips:

  • Keep functions and methods short. How short? His principle is to use extract method refactoring until there is nothing more to extract. I got the feeling that he would consider anything over 20 lines suspect.
  • Have functions with only a few arguments - preferably no more than two - and don't use boolean arguments because they cause confusion.
  • Similarly, a class should be a small batch of code, with only a few variables, a couple of dozen methods.
  • Eliminate duplication in your code; use abstraction.
  • Give public methods short names, but use long descriptive names for private methods. The code is the documentation.
  • Improve code slightly every time you touch it. Sometimes the opposite happens; code decays as fixes get added. If you improve it instead, your project improves over time.
  • You need comprehensive tests, otherwise you do not dare to make changes in case something breaks. Test code should be of the same quality as production code; if your tests are slow and buggy, you will not use them or trust them.
  • Have short iterations. A month may be too long. Two weeks is good. One week, he suggests, may be ideal; or even less in some cases.

You may not agree with all of these; but I like the underlying objective, which is to code to a high standard rather than just fixing bugs until it runs.

Agree? You can sign the Manifesto for Software Craftsmanship.

As I teach and coach project managers, I'm struck by how many are stuck in command-and-control thinking: I must monitor all the work. I must check in with people to see that they are doing their jobs. I must know all the technical details and make technical decisions about the project. I'm sure there's more.

But that's not the role of the project manager. Nope. The project manager exists to create the path for the project team members to succeed. The way a project manager does that is:
  • Select a lifecycle that manages the project's primary risks
  • Help the sponsors define what success means
  • Help everyone define release criteria
  • To be aware of and manage all kinds of risks. If those risks are technical and the pm has the capability to manage those risks, then the PM can make those decisions. But it's more likely the PM has to make sure someone on the team can make those technical decisions.
  • Protect the team's process from outside influence. If the team wants to improve or change their process, great. If someone from the outside wants to impose something on the team, the PM has to protect the team.
  • Allow the team to do the technical work and the pm does the rest-of-the-organization interfacing work
  • Help the team see when they are making progress and when they are stuck.
Now, there are plenty of things the project the PM needs to do around progress:
  1. I like helping people define their inch-pebbles. In the case of an agile team, making sure the stories are sufficiently small. I often discover the team members don't know how to make their work units small enough to see progress.
  2. Notice when the team's process is not helping them make progress. For example, a long build time or lack of continuous integration can impede a team's progress. If you're the one enmeshed in the situation ("I have to wait for the build to finish" or "I have to wait for John to check in his changes") you may not realize you are not making progress. In that case, the pm needs to put a structure in place to make those problems obvious. On a non-agile project, I do this with one-on-ones. In an agile project, I do this standup meetings.
  3. Make sure everyone knows what is most important to work on now and next. I like ranked backlogs, no matter what kind of lifecycle you use on a project.
So, a PM doesn't need to be the center of the project and control everything. The PM can let the team be the center, and facilitate the team's work.

I've written positively about Microsoft's forthcoming Visual Studio 2010, both here and more recently in a review on The Register. I was interested to see a kind-of follow up from Jeff Vroom, making the case for doing without an IDE at all, at least some of the time:

Emacs, Vim, and other editors have basic syntax highlighting and code navigation for an even broader set of formats despite the fact that they lag behind IDEs in features. Though IDEs offer impressive plug-in capabilities, traditional script and config files seem easier to learn and use and ultimately more flexible.

Command line workflows offer a more flexible, less integrated and less guided approach to development. You learn how to use them one tool at a time. Development and adoption of new tools is usually easier as you are not tightly coupling tools into one complex user interface. Admins, analysts, and designers use command line tools, making it easier for them to work with developers when the IDE is not front and center.

I don't see a lot of designers using command-line tools; but even so I agree that there is a case for a programmer's editor with command-line compilation, rather than a huge IDE. The two things I like most about the bare metal approach are speed and transparency. Speed, because a little editor like Notepad++ starts in a blink, handles large files with ease, and does not get in your way. It is odd that performance still matters so much in an era of multi-processor machines with each core running at more then 2 GHz; but it does. Sometimes I am caught out when a monster like Adobe Dreamweaver grabs a file association for something like HTML or PHP. I double-click a document, and wait impatiently while it loads all sorts of stuff that I do not need, when I only want to make a small text edit to the code.

Transparency is an even bigger issue. If you work with simple editors and build from the command line, you are forced to be aware of what files are in your project, what tools you are using for the build, and what arguments you are passing to them. If something goes wrong, you know where to look. By contrast, IDEs hide things from you, supposedly for ease of use. In the worst case, something like a Visual Studio solution can get corrupted and leave you not knowing how to fix it, other than to create a new one and add back the files as best you can.

A similar problem comes with wizards that generate code. It is lovely to have the IDE generate all that boring data-binding code for your forms, until there is some weird bug, the results are not as expected, and you end up tracing the SQL and puzzling over why it is wrong.

Valid points; but I am still going to come down mostly on the side of the IDE. It is simple: there are so many genuinely useful tools in something like Visual Studio that productivity is better. Things I don't want to do without include IntelliSense and code completion, debugging tools with things like mouse-hover variable values and watch windows, visual design tools that generate a ton of code I don't have to write, various refactoring utilities, and build tools that save having to think about make or Ant. Visual Studio takes ages to load, but once it is up and running you can always press Shift-Alt-Enter and pretend it is a text editor.

I am still wary of wizards though; and I value knowing how to do without the IDE, even if most of the time I end up using it. As one of the comments to Vroom's piece notes, if it gets to the point where your programming skills are really IDE skills, you should worry about being so deeply tied to a single platform and way of working.

 

When an industry gets big enough to spawn other sectors that grow parasitically on top of it, then you can tell it has some decent critical mass. And in many cases, that's where to look for jobs, or even start your own small venture.

Take mobile applications, for example. We all know that the iPhone has done exceedingly well as an application platform. So well, in fact, that start-ups are now forming with the sole purpose of measuring just how well. One such startup, Distimo, focuses on analysing trends in the mobile application space. Perhaps unsurprisingly, it found that Apple leads the field by an order of magnitude. At the recent World Mobile Congress in Barcelona, Distimo said that there are 150,000 applications in the iPhone app store, compared with just 20,000 in that of its nearest competitor, Android.

Let's face it, iPhone apps are so accessible that someone might download one for 99 cents sitting on the toilet, instead of leafing through a back copy of National Geographic. Their accessibility can convert into serious amounts of money for developers. Tapulous, a 20-strong development company that makes games and social software for Apple's Jesus-phone, is now making $1 million each month from them. Not everyone can be that successful, but most of us would take just a small slice of that particular pie.

What makes it so bizarre is that Apple is such a fascistic company. People can write any application they want for Android, and upload it to the app store without any third-party arbitration. Apple, on the other hand, has a notoriously draconian app approval policy. For example, it took an arbitrary decision to remove almost all sexual applications from the app store this month -- but chose to leave in apps from organisations such as Sports Illustrated and Playboy. This is unlikely to make developers happy -- but with such a lot of money at stake, who's going to complain very loudly?

The unknown quantity in mobile applications is Microsoft. It chose Barcelona as the venue to announce the mobile edition of Windows 7, which is a marked improvement on all previous versions of Windows Mobile. It's a beautiful looking system, with a sleek user interface, and promised links into services such as Xbox Live, which will be like flypaper for consumers. But not everyone is convinced that developers will support the platform. Beejive CEO Kai Yu is quoted here as saying that the company has simply ruined its reputation with mobile developers too much in the past. There's also the fact that we won't see the first of these phones until the fourth quarter, which puts Microsoft way behind the curve compared to the competition.

But whether you choose the iPhone, Android, Microsoft, or another competitor such as the recently open-sourced Symbian, there are worse ways to make money than by developing a mobile application -- even if you do it on the side, rather than taking it up was your day job. If you can avoid the hundreds of me-too applications out there and do something truly original, perhaps you could even be the next Tapulous.

Not the imaginative type? Worry not, my developer friend. Such is the momentum behind this industry that you can even get away without having an original thought in your head. Organisations such as iPhoneAppQuotes are springing up to connect creative thinkers with the software developers who can make their ideas an reality. But my advice: if anyone comes to you suggesting the ultimate iCleavage app for the iPhone, you might want to think twice.

How do you find IT jobs these days? Back in the day, the print publications were the main source. The first section that most IT professionals turned to when they got Computer Weekly or other trade magazines in the mail was the jobs part at the back. These days, the Internet has taken over as the main source for job seekers, but the signs are that employers and recruiters may not be taking advantage of it as much as they could. And that's potentially damaging, because innovation in online recruitment is speeding up.

Thanks to the economic crash, and the effect on information-centric industries such as financial services, jobs in IT these days are still relatively hard to come by. Almost a third of recent graduates are unemployed, and more than a quarter of those that are in work gross under £10,000, according to CWJobs' recent survey of 5000 jobseekers.

No wonder, then, that IT workers are turning to the web, with its high volume and fast turnover, to track the latest opportunities. Around 70% of respondents use general job sites on the Internet with lots of different vacancies. Around half of all candidates look for job opportunities specifically on a potential employer's website. Just under half of them go to specialist industry web sites to find their next appointment.

Worryingly though, a third of candidates interviewed by CWJobs said that they received no response when submitting a job application online. As the survey points out, graduates who have less job seeking experience may well take that lack of response as a negative sign, and not bother trying again.

As one respondent said: "The key problem is receiving no response. It feels like my applications disappear down a black hole." By not acknowledging responses and feeding back, recruiters risk alienating a valuable segment of their potential candidate base.

While recruiters struggle to nail down even these basic online skills, social media is raising the stakes for candidates and employers alike.
 
Twitter has dramatically grown dramatically in significance in the past couple of years. Whereas it used to be a site for inane chatter about what you had for breakfast that morning, it is now a site both for that same inane chatter, and for more serious things, such as passing on news links, asking questions of your community - and finding jobs.

Take TwitJobSearch, for example. This tool aggregates job postings on Twitter into one easily searchable place. A quick look shows 2000 job postings harvested in a single hour. These are jobs across the world, and in many different sectors, but there is still plenty of opportunity for finding the position that fits you. The site lets you save jobs to your Twitter account, and add your online CV. It also highlights the recruiters who are savvy enough to be using Twitter to post new job opportunities (hello there, @jobs_in_the_uk, and @itjobsldn!)

Still, we have a long way to go before people realise the significance of sites such as Twitter. Facebook and LinkedIn were by far the most-used social media sites among the CW Jobs survey base.

LinkedIn is used more by contractors than permanent staff (roughly a half vs just over a third). This is probably because contractors need to score gigs far more regularly than full-timers, meaning that they have to network more. Services such as Twitter garnered around 10% in both camps.

But 29% of jobseekers surveyed say that they don't use social media sites at all, although given the incredible growth in the popularity of these sites, and the dire situation of the economy following the financial crisis, that is likely to change. As individuals begin to realize that it is possible to find jobs using these outlets, they're likely to catch on and begin firing up sophisticated (and free) social media management tools such as Hootsuite.

So, for recruiters and candidates alike, if you think that social media is for teenagers, now's the time to think again. The web will continue to play an increasingly important part in the recruitment process - and those who choose not to play will be missing out on a big opportunity. 

Microsoft has made a release candidate for Visual Studio 2010 available for download, and the rumour is that the final build should be ready in time for the official launch on April 12th. Should you care?

I'd argue that Microsoft's platform is in decline, despite good financial results recently on the back of the success of Windows 7. Windows-only development is increasingly unattractive in a world where Macs, iPhones and Linux devices such as Android and some netbooks jostle for attention alongside the once all-conquering Windows PC. Microsoft does internet too, of course, and even cross-platform for the desktop if you count what is coming in Silverlight 4.0; but even after the launch of Windows Azure this month, the company is not the first to come to mind when you think cloud.

That said, Visual Studio 2010 is a mighty impressive release. It is not just a new IDE, but also includes .NET Framework 4.0, the first complete update since version 2.0 in 2005. Versions 3.0 and 3.5 used the same underlying runtime as 2.0. The Chief Architect is Rico Mariani, Microsoft's .NET performance expert, which has no doubt helped in the tricky transition to Windows Presentation Foundation for the Visual Studio editor and shell; and much of the product is under the oversight of VP Scott Guthrie, one person who still knows how to communicate with developers, and whose presentation on Silverlight 4.0 rescued last year's Professional Developer's Conference from tedium.

Leaving aside the people involved, there is a ton of interesting stuff to explore, including the new F# language, IntelliTrace debugging that lets you step backwards through code, standard UML diagramming, source code management and issue tracking through Team Foundation no matter how small your team, greatly improved libraries and tools for concurrent programming, and if you have the Ultimate edition and the patience to set it up, an extraordinary thing called Lab Management which integrates virtual machines into the automated build and test cycle so that you can verify clean installs into complex multi-machine environments on every build, and use snapshots to analyse bugs at the moment they occur. This is also the first release to be designed with ASP.NET MVC in mind, and to have a full visual designer for Silverlight. Microsoft has also done some good work with Windows Workflow Foundation, in conjunction with a new runtime for the IIS web server called Windows AppFabric, making it easier to build and deploy applications that depend on long-running state management.

vs2010-rc-small.png

There are some disappointments. One is that Visual Studio is out of synch with Silverlight 4.0, so despite developer attention having largely shifted to the 4.0 release, Visual Studio 2010 will ship with Silverlight 3.0 support. There will be an add-on in due course that will put that right. Another is that Windows Azure development is not as smoothly integrated as I had hoped. SharePoint development, while much improved, remains an arduous process that tends to take over your development machine; and there is not much new in mobile development as yet. I am sure there will be plenty of other problems and frustrations; so much here is new that it is nearly inevitable.

These issue have not stopped me from enjoying my work so far with the beta and now the RC. If you have any interest in Microsoft's platform, I suggest you take a look.

 

Well, Apple's iPad was something of a letdown, wasn't it? The most anticipated product since the iPhone launched onto the global stage not with a bang, nor with a whimper, but with what can only be described as an embarrassed shuffle.

You could tell that things were starting to go awry even as Steve Jobs sat down in the comfy chair onstage to carry out the demo. He was scrolling happily through several web pages, blissfully ignoring the fact that the first one he went to - the New York Times - simply didn't work as it was intended. Why? Because apparently, just like its smaller brother, the iPad doesn't support Adobe Flash.



Tim Anderson wrote recently about the need to develop for the mobile Internet. Mobile search and location-based services will drive the mobile web. Mobile advertising has been growing slower than expected -- recently, research firm EMarketer anticipated a $1.1 billion spend by 2012. The financial downturn has slowed developments, but the potential for mobile Internet revenues is staring us in the face, nevertheless.

This is why Jobs' demo last Wednesday is so significant. The iPad is flawed in many respects. It has no camera. There are no standard ports on the thing. It costs more than many net books, and yet its operating system is locked down. But one of the biggest flaws is that without Flash, many of the sites that we would like to visit are not available.

Such is Adobe's chagrin that its platform evangelist Lee Brimelow published a list of websites including Google Finance, Disney, CNN, popular American media streaming site Hulu, and Facebook application Farmville. None of them were without Flash, meaning that none of them will work on the iPad.

Apple's decision to eschew Flash on the iPhone was irritating enough for Adobe, but to do it on a tablet device that Apple hopes will replace the laptop for many consumers sitting on the couch in the evenings is no less than a declaration of war. Adobe needs to promote itself in new markets like this one, where everything is at stake, and Apple is making it very difficult.

Adobe definitely has cause to worry. Apple's share of the mobile market is only 2.7%, according to research firm Strategy Analytics. On the other hand, it sold 99.4% of all mobile applications last year. People buying Apple's mobile devices use them in ways that users of other mobile platforms do not, and Adobe will be well aware of this, as will Microsoft, which offers the competing Silverlight technology.

And looming on the horizon is a potential game changer: HTML 5. This as-yet unratified technology is nevertheless being supported in its unratified perform in many browsers. It is vastly more functional than HTML 4. Web developers can display video using it, without having to resort to Flash. They can produce HTML-only pages that enable you to drag and drop anything, and edit any content. This is why Google Wave, the search engine giant's revolutionary new online messaging system, was built in HTML 5. It looks and feels like a desktop application.

HTML 5 cannot claim to do as much as Flash can, but it may do enough. Apple, which itself likes to dominate all aspects of its business, doesn't like it when other companies like Adobe dominate a single part of the online experience. What Jobs may have been imagining when he scrawled through that broken site last week was a world in which it used HTML 5 -- and in which Adobe was increasingly irrelevant.

What does that mean for IT professionals and web developers today? It means that understanding HTML 5 as it develops, and honing your skills in this exciting new technology, might not be a bad bet. As this new decade rolls on, you will find it looking more and more attractive on your CV.

Responding to the mobile challenge

January 22, 2010 10:10 AM
Tim Anderson

Few assumptions are safe in the IT industry. A few years back, it was obvious that that PCs running Windows were beating the Apple Mac into a tiny niche. Things look different now. If you planned your IT strategy on the earlier assumption and have not changed, you are now getting it wrong.

Another not entirely unrelated area is the significance of the mobile web. Mobile phones have had web browsers for as long as anyone can remember; but for most of that time actually using them has been frustrating and slow. Remember trying to scroll a tiny window around some web page broken by non-functioning Javascript or CSS, looking for a critical piece of information such as an address or schedule?

In consequence, the extent of mobile browsing was small and mainly focused on niche areas like travel.

It all changed with the iPhone. Those contracts are expensive, but once you buy in you generally get an unlimited data connection, and more important, a decent browser which is a version of Safari, built with WebKit. That same engine is now used in many other devices, not least those running Google Android. Suddenly, users do want to use their mobiles to browse the web; and they will be hitting your web site or application and trying to use it.

Check your stats. I run another blog at itwriting.com, and when a reader complained about its appearance on a mobile, I added a wordpress plugin which both fixes the layout and reports the traffic. According to the plugin, 5% of the traffic was from mobile users. Once the site was fixed, the figure grew dramatically, to over 15%.

A tech news blog is just the sort of thing that appeals to mobile users, so those figures will not apply in every case. The point though is this: all those assumptions about limited mobile usage which once seemed safe now no longer apply.

Here's another line I often hear. There's no need to optimise your site for mobile, since the more advanced mobile browsers work fine with normal web sites.

Unfortunately that is not the case. They work much better than older ones, true. However, the displays are very much smaller and the connection speed often much slower than on the desktop. If you want your site to be a pleasant experience for mobile users, you will likely have to deliver customised content for them.

Does everyone get this anyway? If you have a few spare minutes, head over to mobiReady and try out a few sites; or download the Android emulator; or of course use a real device to test sites that you are involved in or interested in. I did so before writing this piece, discovering that the web still looks very broken once you go beyond the top sites.

The positive spin on this is that optimising for mobile can be a relatively easy way to gain commercial advantage.

Talking of safe assumptions, one that seems good right now is that the number of web-connected mobile devices is going to grow rapidly in the coming years. Optimising for mobile was always the right thing to do. Now it is essential.

 

It's good to talk, or so the saying goes. So, why aren't candidates for IT jobs talking to their recruiters, and vice versa? Recent survey statistics suggest that the two factions aren't on the same page when it comes to job requirements -- and that it is creating a skills gap.

The data, which came from a survey of 1560 IT professionals and 38 recruiters by CWJobs.co.uk, found a marked lack of communication between recruiters and candidates. That's going to hurt everyone, including the clients, in the long run.

The problem, according to recruiters, is that job candidates don't have the skills that they need. But job candidates feel that the recruiters are not very good at explaining what they want. 59.6% of candidates said that employers are not clear enough about the skills they expect when recruiting for technology roles. And, surprise surprise, 65.8% of recruiters felt that candidates are not clear enough about the skills they have when they apply to jobs.

This is leading to a mismatch in skills. Six out of 10 employers want C# skills, according to the survey, but 74% of technology professionals said that it wasn't an integral skill in the current market. 84.5% of them also said that ASP.NET wasn't an important requirement, and yet half of all recruiters want it.

So, in addition to some better communication skills, there clearly needs to be some retraining. IT professionals say that they need to retrain in SQL, .NET, Java, Oracle, and Linux. Recruiters said that SQL, .NET, and Java will be important skills over the next one to two years, in addition to C#, and PHP (which still didn't feature highly on job candidates' lists).

One interesting snippet is that recruiters cited soft skills such as business acumen and understanding user requirements as an important skill in the future. Perhaps this would also enable job candidates to communicate their skill sets more effectively. But recruiters need to do the same, and learn how to articulate what they want.

This is something we clearly need to fix. This IT skills gap has arrived just at the point when the economy is beginning to recover (if the Bank of England is to be believed). Companies are starting to invest in new projects, and will need the technical expertise to implement them. The jobs are apparently waiting to be filled, but the whole situation is like a bad date; although each party is looking for someone else to be with, they can't seem to hit it off, because they are not on the same wavelength.


Every project needs a project vision: the reason the team is working on this project.

When you define the project's value early in the project, the more the project team is likely to tell you whether the project makes sense--or whether you're starting an impossible project. If you can't articulate the vision, chances are good that you're starting on an impossible project, because there's no way to end a project with no vision. A useful vision is compelling to the project team. And it helps the team make decisions about what's in or out of the project.

Here's how you create the project vision:

    1.    Define who the primary customers of the project are. They could be the mass market, existing customers, new customers, or a specific market segment.
    2.    Define the one major focus of the project. This could be a specific feature, or the general approach. If you're new to agile and you're starting a pilot project, you might want to say, "Use agile techniques to see how to adapt them here." A project doesn't focus on five things; it focuses on one overall vision. If your project requirements are too broad to encompass in one vision statement, maybe your project is really a program.  A project has one deliverable. A program has one overall deliverable and is composed of sub-projects, each of which has a deliverable.
    3.    Write as much as you need to, and then edit until you're down to two to four sentences. If your vision is longer than four sentences, you haven't described the project focus yet.

Here's how I do this. With the project team, we decide who the primary customers of the project are. Now, if I know the major focus, I explain it. Otherwise we try to define it together. Now, as individuals, we write our sentences, on stickies. We post them on the wall, and read them out loud, seeing which sentences make sense. We choose sentences and edit. Once we're down to no more than 4 sentences, we are done.

If you're on a project without a vision, stop right now. Take 30 minutes, define it, and get back to the project work. The whole team will benefit, as will your customers.

Current Vacancies from CWJobs

(* Required field)










Preferred format