Single to Multi
I never predict the future, and never will again. The next evolution of software development is looking very much like widespread adoption of multi-core applications. As the much-quoted and much-abused Moore's law starts to plateau just a little, the vertical exponential power curve is rotating into a horizontal one.
So far, the market has seen two evolutions of the single to multi model. One is in hardware, the other software.
Hardware
Instead of increasingly powerful single processors for you to build and execute your code against, desktops and servers are being sold multi-core as standard. This means having a huge pool of workers processing and calculating in parallel, handling your work tasks in a massively co-operative way. There are three manifestations of this: the multi-core processor in one server, multiple single-core processors across multiple servers, and multiple multi-core processors across multiple servers.
All of these scenarios can be leveraged to deliver greater speed and power in your applications. For this, you need software.
Software
Most legacy and current applications were designed and built to execute on single processors. This makes sense, as most processors out there in use are singular in nature. At least, that's the standard reason. The other reason is that designing and coding multi-core applications is very hard indeed. If you abstract the challenge into human terms: it is always easier to manage one person who is solving a problem for you, than it is to manage a team who have to work together on that problem. However, if you can create an effective team who can together effectively on one or more problems, you always get better results, faster. However, team members occasionally fail to communicate, or try to do the same thing at the same, or overwrite each other's work. Poorly designed multi-threaded applications can cause the same problems. So, the technical use cases and solution design have to be thought through very carefully, and intelligent safeguards for the inevitable resource battles designed in.
Result
Multi-core is likely to become the default model for software design and development. We should all start looking at our technology stacks, software architectures and programming languages, and decide how to prepare for the explosive potential of multi-core.
Your Initiation
No, this isn't a rugby or frat boy reference. It's getting your key project parameters right before you start designing, writing, or coding.
Many web projects are kicked off and conducted at a clattering pace. The time pressures from clients can be very hard to resist, and often it is hard to explain to them why going more slowly can be to their ultimate benefit. Whatever the anticipated velocity of your project though, a phase of Project Initiation is absolutely vital to improving your odds of success.
Project Initiation has a bad name in some agencies, due to the classic output of a Project Initiation Document (PID). Anyone who has worked on a COI project, or with any large corporate entity, is likely to have been forced down the Prince2 road. The first major deliverable in Prince2 is your PID, and they take a huge amount of time and energy to write. The PID is the baseline document for the project, a document against which all future change requests and, ultimately success criteria, will be set. This is means that It Is Very Important.
Unfortunately, something as monolithic as a PID mitigates rather directly against Agile methodology. Rightly (in my view) variants of Agile are now embedded in most agencies and tech shops that deliver web sites or web apps. Don't doubt though that you still need to Initiate Your Project. Just not with a 101 page epic that is full of hopeful forecasting and mind-soaking detail.
Project Initiation is not as relaxing as this.
To solve this challenge, I have developed a much more lightweight project initiation methodology for web projects. Instead of a huge slab of document, I put together 2 small, but concise documents:
Project Brief
A description of the project essence - origin, aims, success criteria, timeline, budget (if fortunate).
Statement of Work
A capture of all of the key parameters for the project -features, deliverables, assumptions, risks, timeline, budget are the main elements. Yes, it does sound like a PID. The key difference is that it does not attempt to set in stone the kind of detail that will be reversed much later. It concentrates on the core elements that must remain more or less constant. More importantly, it concentrates on elements that really do cause arguments later. Most projects can handle the move of a screen, or change of a design feature. What they cannot survive is a meltdown of budget, timing, or basic features. So get these agreed up front, link the features to the timings to the budget, and you can have a safe, robust, and clear basis to engage your designers, UX architects, and technologists to create a fantastic piece of work.
Command and Control
To deliver consistently high-quality web sites or applications, a robust and scaleable release environment is absolutely vital. My philosophy on release management is this : let the coders code. They don't want to worry about getting code to dev, or staging, or test, or to any other server. They want to commit, and then it just gets there. They feel the same way about bugs - if you have to give them bugs to fix, at least run them through a decent tracking system.
Always have the latest tools at your fingertips.
Finally, if anything goes wrong with your site or app, you want to know straight away so you can fix it. You need fantastic monitoring and notification.
My tools of choice:
- Source control : Subversion (SVN). It's a true modern classic, and pretty much every developer knows how to use it. Never underestimate the value of that. Alternatives include Mercurial ,Git, and Visual SourceSafe. The first two are new types of source control system, known as Distributed Version Control. The third is an old type of source control system, known under a few names not suitable for a family blog. It is a Microsoft product that integrates with Visual Studio, so it is widespread.
- Bug Tracking : Trac . Not as widely embedded as SVN, but a lightweight issue tracker with wiki capability. It also have a native SVN integration. Alternatives include Bugzilla and Mantis.
- Continuous Integration: Hudson . the butler will always ensure that your site is built per commit, per hour, whatever you need. Hudson will also show complete outputs of errors and issues with your build, before deploying it to your target server. Indispensable on larger projects.
- Functional Testing - Selenium. Great tool for setting up automated functional tests.
- Cross-Browser Testing - Adobe Browser Lab. early days for this tool, but you can see any web page rendered in every conceivable browser. Not too scalable for large sites, but indispensable for smaller projects. Free to use if you register before April 2011.
- Performance Testing - JMeter. You can go as hard or soft with this tool as you want, but there is a certain pleasure to be gained watching your site serve, slow, and die. An alternative for simple and brutal is Apache Benchmark (ab).
- Monitoring : Nagios . Proper server monitoring for the enterprise - vital for ensuring your servers stay up, and fast.
- Hosting: Amazon EC2 or Rackspace Cloud . There is rarely an argument for managed hosting in my line of work, should you have the luxury of the decision. Amazon are cheap and quick to deploy, but Rackspace are unmatched in my experience for support.
I have used plenty of other tools, but I would march into digital battle with this lot and feel confident about doing a great delivery job.
The cross-device conundrum
Another cracking debate you hear a lot in agencies and beyond, is whether site owners should build a flexible site that serves into desktop and mobile browsers, or whether they should recognise the channels as different to justify a "www." version and also an "m." version. My view has always been that the two environments are so fundamentally different that it's a fool's errand to attempt to stuff the same code base into both. It is possible that the ongoing convergence of desktop and mobile browsers will allow for less separation of the two content types. I remain convinced however that the differences in screen size, portability, available bandwidth, and typical user desires are different, and should be recognised as such.
Why am I so inspired to post on this today? The answer is Opera, with a capital "O". Yes, the purist's browser maker is the place to go if you want to learn about true standards adherence. They have published a concise, wittily-written, and comprehensive article on this very topic. I counsel you to read it - on any device you want.