mobcode

Respect the web

As an enterprise architect I spent years holding web technologies in disdain. Sure, you could make some neat little pages but it was certainly no way to build real apps. Over the last few years I have seen the light and come to appreciate the wonderful, messy, hacked-together, really useful real world of the web.

So here is my guide:

1. HTML - It is not just an inconsequential view that may be used to render your data. It is a really useful way of marking up data, not just for browsers to view but for code to parse. Forget custom XML schemas. Use HTML. If your data is in HTML then your code can parse it easily, your browser can render it easily, and you can use CSS to format it nicely.
2. HTTP - Don’t dismiss it as some low-level communication layer that you will use to tunnel your application protocol. Embrace HTTP as your application protocol. Read the spec. See what it offers and use it. Even if you don’t have a web client use HTTP to communicate with your server. Don’t bury HTTP at the bottom of the protocol stack, but embrace it and build an app to use its features.
3. JavaScript - It is not just a toy scripting language for creating pop-ups or doing validation. It is a powerful dynamic language in its own right.
4. REST - Learn about the principles that have made the web the success that it is. Embrace these principles in your own apps.

Even if you are building “enterprise” apps use web technologies. Even enterprise applications need to inter-operate and that is what the web does. As Mark Baker says, the web is the distributed object system you have been looking for.

Use SlimTimer to track your time

A friend of mine turned me on to SlimTimer and I really like it. It is a web service in which you create a list of tasks you are going to work on. Then you can click one of them to start a timer that tracks how long you work on it. Simply click it again to stop the timer. Alternatively, you can simply click another task to start the timer on another task. It couldn’t be any easier. The application also includes a nice set of reports to analyze your time.

So why would you want this? If you are working as a freelance developer you need to keep track of how much time you work on each project. This isn’t like the old days where you show up at work at 8:00 am and leave at 5:00 pm and record 8 hours of work on your timesheet. These days you are working at any time of day, switching between projects at a furious pace, and switching in and out of work constantly. You need something like SlimTimer to cope.

And, even if you don’t need to track your time for billing purposes you still need a tool to track your time. At some level we are all managers. At a minimum we are all responsible for managing ourselves. You can’t manage yourself without data. So use SlimTimer and collect data about how you spend your time.

You know how it feels at the end of the day, when you say “where did the day go?” SlimTimer will help you answer that question. And, the answer will suprise you.

Besides all of that, there is another reason to look at SlimTimer. It is a very well executed service offering. The author has obviously paid great attention to creating a good user experience, he is blogging about it, and he makes it very easy to get started. If you are working on making your contribution to the web service frenzy, then be sure and check out what he has done and emulate him.

Be ready to ship at a moment’s notice

The software game is unpredictable. The customer might decide they need the software today instead of next week. Or the priorities might change and you will be called off of your current task. To ensure that your work is not wasted it has to be ready to ship at all times.

Do your work in such a way that is is always done. Not that it is completely done, but it is always partially done. The key is that it must be ready to ship at a moments notice.

How do you do that? You first implement features as thin, end-to-end strands. Then you bulk it up one additional strand at a time. To put it another way: first get a rough version of the feature working, then add the bells and whistles, one-by-one.

Don’t thrash

Another way developers act like computers is they thrash. You have seen your computer do this. You try to run too many things at once. The computer runs out of memory and starts swapping to and from disk. You hear the disk grinding and performance grinds to a halt as the computer is stuck constantly swapping back and forth to disk. Nothing gets done.

This is most obvious in developers when they take on too many tasks at once. Either individually or as a team. There are so many different features under development that all of the time is spent switching between tasks. The developer is rushing around from task to task. Much energy is expended. There is much activity. But as the activity increases the amount of work that gets done decreases.

Perhaps this is seen as a flood of emails flying about. People are asking questions, getting confused, trying to establish the background understanding, and this is all happening on twenty features at once. It is too much to keep organized and so the efficiency plummets.

The solution: do one thing at a time. Pick a feature, talk about it, prototype it, repeat a few time until it’s done. Then move on to the next one.

Developers should not halt

Developers tend to become like the silly machines they program. When a computer runs a program and encounters an unexpected situation it halts. The program stops running. In some cases the computer stops running. If the user want the computer to start again then it is the user’s responsibility to go in, remove the offending data and restart the program.

Sometimes developers do this. They are asked to do something, they start to look at the problem, they encounter something they don’t understand and they stop. Maybe they come to a crossroad and they identify two choices. Maybe something like: “should this be implemented as a database constraint or in application code?” Unsure of which choice to make, they take the fatal choice of stopping and punting the issue back to the sponsor.

This always feels arbitrary to me. Any problem can be divided into an endless set of design choices. Any one of those choices could be declared a show-stopper and bang… development stops.

If developers don’t feel empowered to make the choice then why do they feel empowered to halt?

Needless to say halting is not a desired behavior. Imagine this happening in a cluster of many developers. The project sponsor must walk around resetting stuck developers all day.

Resume advice from Joel

If you are applying for a job and you want to increase the chances of getting noticed then read this. Don’t just bookmark it, don’t just read it, but read it and compare what he has to say with your resume. In particular evaluate your resume and introductory messages according to his standards of:

1. Passion - Do you show that you are really excited about what you do?
2. Pickiness - Are you particularly interested in this job? Or are you equally interested in all jobs?
3. English - Not just do you know English well, but can you think clearly and express your thinking in well formed, coherent sentences and paragraphs? (Did I just fail that test?)
4. Brains - What have you done that shows you are really smart?
5. Selectivity - What tough, grueling challenges have you overcome that show you are in a select group?
6. Hard-core - How have you dug deep into technology to really understand how things work?
7. Diversity - What is unique about your background or experiences?

You will either have these things or you won’t. If you have them, then make sure you show them when you apply. If you don’t have them, then you have a long road ahead of you because they don’t come easy. But at least you know what you need.

Version control software - add it to your toolbox

Whether you are a coder, a web guy, or a technical writer you need to know about version control software. Without version control software you end up with numerous copies of files floating around on everyone’s machines and you never know which version is the latest. Or you make many copies on your machine and name some of them “file_v2.txt” and put some in the “old” directory so you have a backup. It is madness to keep track of.

That is what version control software is for. You put the files onto a server and that is the “master” version. Everyone gets the latest version from there and puts there changes back into the server. The server keeps track of all of the different versions and allows users to see who made what changes when.

This is important for writing code, for creating style sheets for web sites, and for writing technical documents. You need to learn how these tools work in general and how to use some of them specifically. The products include things like Perforce, Subversion, or even the older CVS. Or if you are in the Microsoft world you may encounter (the utterly miserable, but I suppose better than nothing) SourceSafe (I find it mildly amusing that the lady in the SourceSafe graphic appears to have devilish horns coming out of her head).

As a professional in the computer industry you need to know about version control software. It is a basic capibility to have in your toolbox. It is especially important when working with a bunch of other people on the web.

Build two to get one

When I attended this software development conference a couple of years ago there was much talk of how to decrease risk on software projects. One suggestion that came up several times was having two separate teams work indepedently to implement the project. This seemed to be mentioned, not as a real possibility, but merely as a thought experiment.

If you work on the web there are two factors that turn this thought experiment into a real option:

1. High chance of failure
2. Cheap development

When a project sponsor hires a developer across the web there is a good chance the developer will never produce anything useful. Or the developer will be so busy on their day job that they can never focus on the project. Or there will be communication issues that prevent you from ever establishing a good working relationship with them. Not to mention all of the normal project risks that make every project take much longer than expected. This is a problem. It is hard to have confidence the project will be done soon.

But, global competition on the web is driving software development costs down. Project sponsors can afford to hire two developers to work on the exact same thing. This basically doubles the chances that the sponsor will get working code.

Often when developers find out this is happening they are concerned. It seems so inefficient. It just seems wasteful and wrong. However, developers need to understand that there are different parameters to optimize. Instead of trying to optmize the project cost, the sponsor is focusing on the need to deliver.