Equivalence

In a recent podcast Jeff Attwood and Joel Spolsky were discussing the virtues of email. As a somewhat brief summary of the discussion I think it’s fair to summarise that Jeff hates email. As it happens I’m inclined to go along with him on this one, but possibly for different reasons.

From what I can gather, the problem Jeff and Joel were describing with email is that we end up with an inbox full of emails that never get read or processed, and to allocate the time to process these mails and respond would be a job onto itself. To be honest, I don’t suffer this problem quite as bad, mainly due to the fact that I do not receive in any shape or form the level of email that both of these guys do. As a result, it’s hard for me to appreciate the hate of email for the same reasons. However, I feel there is a far more toxic fallout to the email culture than that which is described.

It has come to my attention recently that many (large) organisations still use email as a way of providing an API to their service. What do I mean by this? Well, in this digital age it is often the case that a web application uses the API provided by another web service to interact with it. For example, if I want to receive a list of the tweets that I’ve made, the twitter API allows me to do this by accessing a given URL, and returns the data in the format of my choosing. Similarly, I can also publish a tweet by posting data to a given URL. This is all rather nice – everything is communicated over good old HTTP allowing easy integration with other services.

However, many firms that are not technologically aware are using email as a mechanism for inter app communication. I don’t want to bash individual companies here but the ones I have personally dealt with are multi-national companies with profits in the billions. Yet despite such profits margins their software systems look like something seen in War Games. To perform any communication with these systems you send an email, and responses are returned to you via the magic of an automated email. Thus, you have to parse the email body and/or parse an email attachment to get the response data. It’s as if Web 2.0 passed like an amoeba in the night without these companies so much as blinking.

You may say that it must work for these companies to be making the profit margin they do. However, as customers, we are paying thousands on development costs to integrate with these systems – in many cases we have no choose in the matter. At the end of the day these companies are slowly falling behind and if they are choosing not to innovate at this level, I personally don’t hold out too much hope for innovation on a wider scale. This kind of strategy no longer works, Google and other such companies have long since blown this way of doing business out the water. No-ones’s saying the death of the non-innovators is going to be quick!

So what is the message I’m trying to get across? Well first, email for this style of inter app communication isn’t really helping anyone. If you are thinking about doing something like this, please think again. Also, on a more general note, can companies that fail to innovate survive in this technology driven society? It’s obviously hard to answer this question with definite authority, but going by gut feeling and history, it doesn’t look good.

Observations future of email, innovation, technology

Right, so I’ve been thinking about this for a while now. It’s a question that has been contemplated more times than anyone cares to remember, and still we have no good way of achieving the goal that it sets out. A quick search on Amazon will probably yield a thousand books on the subject – each and every one making you think the next is the holy grail. So am I going to tell you the question?? Well I suppose I must.

What is successful software? I’m sure the exact definition of this is subject to opinion and means different things to different people. Therefore all I can do is bore you with the details of what I think makes successful software:

1. Software that the end user is happy with – a no brainer, if no one wants to buy or use it then you may as well give up. Happiness encompasses how the software looks, the user experience, and the functionality.
2. Software that is finished to schedule – no one likes to wait, from management to clients, and even developers. Software that is late causes stress on everyone. Scheduling is hard and it has to be realistic. The end result of cramming and cutting corners is poor quality.
3. Software of high quality – you can finish on time but if it doesn’t do what it needs to do in a manner the user expects, or simply is littered with bugs, then there is not much to be cheerful about. It has been documented ([1]) that bugs caught early can mean 1 hours spent now can save up to 3 to 10 hours later. As a result bugs caught after release cost between 40-50% more. This is always worth keeping in mind.
4. Software that is cost effective – achieving all three things above but at a cost which prevents profit does not make sense. Costs are important and developers should also be mindful of this – even for internal software.
5. The developers are happy and proud – I’m sure there are many employers that would be happy if they got software that satisfied the first four criteria but couldn’t give shit how their employees felt or what it took (out) of them. Stressed out employees are no good, they will only leave, and sooner rather than later you will find that you can no longer attract those employees that are smart and get things done. It’s surprising how easy it is to keep people happy without spending a lot of money.
6. The management are happy and proud – if all the above is achieved at the expense of a stressed out, worn out, nerve shattered manager, then the same problems that arise with unhappy developers can be seen in management with the same negative results.

Now that we have a definition of successful software we can ask the natural question of how to achieve this. As I mentioned earlier, there are more books that I care to read telling me how to do this. Yet I feel none of them can apply in every situation. They all preach some methodology from the latest fad to the decidedly idiotic. If any one of these methodologies actually conclusively worked, there would not be as many books. I’m convinced that the truth lies somewhere in between them all and depends not only on the organisation, but on the people involved. So surely those involved in creating the software may have a better perspective on what will work than the author of a book? (This is not to say you can’t steal ideas that you have read and apply them in a suitable manner.)

I have my opinions on what I think would work for me, and is something that I can probably document in a follow up post. For the moment I will leave this with the statement that don’t be frightened to break rules and invent your own when something is not working. This is the only way we can make our software more successful.

[1] Rapid Development – Steve McConell

Observations, lists development methodologies, software cost, software quality, sucessful software

There comes a time in every programmers life when they have to learn new things and step out the box. Yeah it’s difficult, for sure. It’s all too easy to create the latest application in your software empire, using a language you’ve been developing in for the last 10 years. However, the real problem is thinking this is the only choice. When is it time to abandon this certitude?

First, we cover the forced abandonment. This is when you are pushed kicking and screaming into pastures new, whether you like it or not, i.e. the new job. Here, not only is the new language curve ball thrown (viciously), but you also get whole new set of business rules into the bargain. So what do you do? You program the new language like the old one, only translating the syntax in your head. This is not the best way to learn a language though. Why? Well consider those C programmers trying to program imperatively in Java, Java programmers in JavaScript, C++ programmers in Ruby, and so on. When there is a change in paradigm this mapping strategy just doesn’t work – a similar situation exists with languages that contain a more powerful expression set. It also encourages the behaviour where people learning enough to get the job done, without understanding what is really happening, or that there may have been a better way using “unmappable” language’s features. A better approach would be to write something small, and new, that allows you to explore the language’s features. I’m sure most people can think of something they could write. Furthermore, if you can make it useful to other people, or even your new employer, then everyone’s a winner! This is something I touched on before.

For many people though, this is the only time they will ever consider abandoning. This is sad, and a poor characteristic in a programmer. And to be honest, I just don’t understand it. That’s not to say that I don’t accept that people just do programming as a job, then go home and don’t think about it. However, it’s like most things in life, it’s nice to progress?

As a programmer there will also be other signs that the tide is turning, and you don’t have to be too alert to spot these. Previously I wrote “Perl is Dead, Long Live…Perl?” and being a big Perl fan it was sad to see the language apparently dying, so I know what it’s like. Some signs to look out for may be:

• the language features are not moving on (Java watch your back) – the people who created it no longer care,
• the community surrounding the language is dwindling – the people who use it no longer care,
• there is little in the way of choice when selecting libraries/frameworks – the experts have fled,
• other programmers have never heard of it – there is no buzz,
• jobs using it are few and far between – businesses have given up on it, the death kneel.

However, this is all not to say that you give up on your language just because it’s no longer cool – popularity is by no means a great indicator that something will suit your needs. It need not be the case that you give up on your language of choice, instead it could be that you contribute and drag the language forward. But be careful with this one.

Finally, any decent employer will want to see that you are continually developing your skill set – their business needs are continually evolving, so why aren’t you? You are much more likely to land a better job if you contribute to your own education in some way. It looks good and it’s also something to talk about.

So go out and learn something new today, and stop sticking with what you know.

Observations, programming C#, education, Java, JavaScript, jobs, learning, programming language, Ruby

Programmers at times can take themselves, and their abilities, a little too seriously. The fact is that programming, in general, is just not that difficult. Sure, there are parts of it that are tricky but, at the risk of over generalising, the capabilities required by your run of the mill programmer are not that high. Are you sure I hear you say?

Well plucking figures right out the air I’d say that around 90% of applications involve a simple CRUD model. So what we are essentially doing is gathering data, processing data, and writing this data to the database. Two-thirds of this process is pretty simple, i.e. gathering the data and writing it to the database, this leaves the possibilities for hardness in the processing data phase.

Again in most situations the processing of data is pretty simple with no complex db manipulation or algorithmic mind games. Consider your typical web application for example. The processing of data is minimal, with little to no algorithmic work involved at all – I mean with Twitter there is literally nothing to do. Google on the other hand has lots to do: it has to make those search results shine. This is not to say that developing Twitter is simple, as the scaling issues will make your head hurt. However, scaling problems are only going to affect a very very small number of sites out there, but due to their ubiquity they are the ones we hear most about.

If all this programming nonsense is so easy then surely it’s difficult to make bad software?

Nope. The fact is that the only people who care what the code looks like are other developers. The code underneath could be shitter than an incredibly shitty shit and the end user wouldn’t know. As long as it carries out the task that they require the software to do, in a reasonably efficient and user friendly way, no one really cares. Oh apart from other developers.

Obviously nice structured code, that is easy to understand, free of bugs, and a maintenance dream is a good building block. However, it is by no means a guarantee that you are on to a winner. Marketing, user experience and coolness are all equally important, actually, they are probably much more important. I obviously can’t say for sure but I would imagine there are plenty of successful software products that are badly written but tick these boxes – maybe even most successful products, as they are free from the burden of the studious programmer.

So, essentially what I’m trying to say is that despite programming not being that difficult there are many other more important factors that contribute to the success of a software product. Many software products do their job, but the one that will be successful is the one that does it well.

All this is not to say that programming well is not important. On the contrary, it’s important to other developers who you work with and that is not to be underestimated. This is a topic for discussion another time though!

Finally, for those non-programmers out there, don’t start shouting “If it’s so simple why does it take so long”? Well just because something is easy it does mean there are not lots of easy things to do. I mean, hammering a nail into a piece of wood is pretty simple, right? But if I asked you to hammer 10 million nails into a bit of wood it would take you a long time. Remember this marketers and project managers.

Observations, architecture, marketing, programming good practices, programming, sucessful software

We’ve all had it drilled down our throats that development should be completed in short-sharp iterations. “Release early and release often” – no agile developer gets up in the morning without repeating this mantra to themselves before they reach the sink. However, surely it’s important to realise the difference between “Release early and release often” and “Release utter shit early and release utter shit often”.

Who really wants to use an application/toolkit/library that has so many bugs in it that the user experience is dreadful? Surely users would rather wait a few more weeks for something that is, in a sense, polished? I mean we’re not talking Microsoft Vista style release cycles here, but quality control consisting of a little more than running a set of unit tests would be nice.

So what has prompted this minor rant? Well Firebug unfortunately. I hate to criticise it because it’s free but the bugs I find in it are getting worse and worse. The most recent one being that the continue button no longer works in the latest release (1.4.0b10). Sigh. However, open source or not, my feeling is that if you choose to do something then do it properly or not at all.

Anyway. Regardless of the product, it surely makes more sense to sacrifice your release schedule a little for some real testing and bug fixing? For commercial products a bad user experience is going to make a sale difficult both now and in the future. Being first to market is one thing, but it’s far from being the only (or even main) contributing factor to a products success – Google and Facebook being good examples of this.

So is it possible just to have a little common sense about all this and maybe restate the mantra as “Release quality early, release quality often”. It can’t be that hard, right?

Observations, startup agile, firebug, iterative development, JavaScript, testing, user experience

I’m sorry, I’m sorry, but I object to the use of the word geek. I’d always imagined that a geek was someone who was obsessive about computer programming. Lately though I’ve seen people use it in a way that is beginning to annoying me – it’s used to describe someone who simply uses the latest and greatest software or gadgets. This was brought to a head when I clicked a link in a tweet (thanks Colin!) which sent me to an article called “Top 10 Ways to Provoke a Geek Argument“.

I mean, I like to think I’m a geek, sad, but true. However, if the things mentioned in that article are likely to incite an argument in a geek, then I ain’t a geek. True geeks laughs in the face of such insults. So bearing all this in mind I say a real geek is someone who takes offense when:

1. someone states that programming is just a day job;
2. someone tells you they work in IT/computing and they can’t program – this often comes in the form of a third-person telling you their friend works in IT just like you!
3. someone tells you that the technology used doesn’t matter;
4. someone’s role call of programming languages does not extend to at least 4 and they don’t know at least one dynamic language – real brownie points go to those who know a functional language;
5. someone shifts a conversation about programming to something else – oh yes, including girls, well maybe not!
6. a developer tells you they don’t have broadband at home;
7. someone states that Agile development is essentially the same as the Waterfall model;
8. someone becomes a “developer” during a one year Masters conversion course – in particular sociology and arts students;
9. a “developer” tells you they want to be a manager;
10. people don’t think they’re a geek.

There you go, if you don’t agree with these then you ain’t a geek! However, you are at least one tenth of one!

Observations, programming

Developing software that nobody wants is a classic mistake.  Joel Spolsky once said that if he had listened to what his customers wanted, and created a product with only their suggestions, they would not have came up with as many nice features (I paraphrase from an episode of the stackoverflow podcast). However, maybe his logic is slightly skewed. Why? Well he is developing a product for software developers (FogBugz). Therefore, his target market is essentially the same people who are writing the software. This makes developers a great source for feature suggestions.

However, consider on the other hand the average software developer. They are not creating a product that is used by other software developers. Instead, customers can range from a highly technical audience (say Matlab), to a secretary with little computing knowledge. Clearly if we are creating a product aimed at the latter market, a software developer is the last person you should be asking for feature advice.

Unfortunately, misaligned product requirements actually happen in the wild. I have been involved a project that forced a user into making around 10 clicks to achieve a particular goal. Each step was valid, and allowed the user fine grained control over a feature. However, the user didn’t need this level of control, and they simply selected the same options every time. There was great difficulty convincing most of the developers that this kind of fine grained control was not required. Thus: developing software without thinking about how a customer is going to use the software should be high on the list of UNFORGIVABLE sins.

Some problems, like the one described above, are hard to grasp for us programmers. As programmers we are taught to generalise, and I think we find it difficult to turn this off in our heads. This can be seen in many applications that drown us in XML configuration. Product managers, and CEOs have less room for excuses.

So how do we ensure that we are not developing software that nobody wants? It just seems obvious to me that you have to ask the people that will be buying your software. This seems so simple right? Can you even believe that it doesn’t happen? Is it beyond the realms of possibilities that somebody, somewhere, is developing a piece of software for a market without asking that market the features that they want? You’d better believe it. It happens all the time.

Observations customers, developing software, Joel Spolsky, software requirements

First, excuse the inherent contradiction in the title! Now, with the recent rise of stackoverflow.com as a programmers favourite dynamic and responsive encyclopedia, I find myself questioning my own behaviour.

Why? Well, I find that I almost NEVER ask any problem-based programming related questions to my peers.

Don’t misunderstand me here, the amount of stuff I don’t know is literally unbounded, it’s just that I will always work away at a problem until I have found the solution myself. I’m pretty sure that I didn’t always do this – I can vividly remember asking a friend with whom I worked with years ago many many programming related questions. Thinking back to those times though, it almost felt like I was cheating asking so many questions.

However, in the last 5 years, much of the development work I have undertaken has been as a contractor. In this setting I literally had no-one to ask. So what did I do? Well I just spent the time researching the problem, figuring out details, and then tried to use what I had learned to solve the problem – where the range of problems encountered ranged from the trivial to utterly complex.

This habit of not asking questions has continued with me. Even on a recent project I encountered several issues that literally had me stumped.  Yet with a lot of effort and hard work, I got something that worked in the end.  This, maybe wrongly, leads me to believe that those who ask a lot of questions are just not willing to put this kind of effort in – I suppose it’s that or they are just not capable! Or maybe they just prefer to economise their effort! Myself, I just think it seemed much easier to ask, and so that’s what I did. But that really just boils down to laziness. Right?

What can we tell from those who ask a lot of questions and those who ask none?

Despite my previous remarks, I think it’s easy to see why asking questions is a good thing: it saves time, builds communities, and most importantly it allows you to benefit from other people’s experience. That said, I feel that a developer who has the ability to free think, and “discover” a solution is extremely valuable – you may not always be in a position to find an answer to your burning question, especially if it is highly tied to the business logic of your application. I’m sure many of those people who ask the most trivial questions would benefit from the process of finding their answer, rather than being given it on a plate at the likes of stackoverflow. Is the success of stackoverflow the first sign of the dumbing down of programmers or is it the start of collective knowledge transfer that can only benefit our whole field?

The link between free thinkers and those who do not ask questions is not an if and only if relationship – anyone with any experience of tutoring students will know this. Many people who do not ask questions actually don’t have a clue (and maybe never will).  You see this all the time with certain students; they never say they have a problem and they don’t ask questions. Then you see their exam results and think WTF.

This leaves me with a problem though: I don’t want to say that all free thinkers don’t ask questions, and I know those who do not ask questions are not all free thinkers. How do you figure out what is what? Mmmm, maybe I will just leave that as a question

Observations programmer questions, software development, stackoverflow

I have forever viewed Google as the ubiquitous dream maker for the software engineer.  You work on great products (Google Search, Gmail, Google Reader, Google Apps,  Google App Engine, the list goes on), and they appear to treat developers well (20% time, free lunches and drinks, gym membership, and more). However, it seems that not everyone is happy if a recent article (entitled Why Google Employees Quit) on Tech Crunch is anything to go by.

It’s understandable that people who no longer work at Google may have reasons to slate their previous employer.  However, these people did not go out their way to highlight problems at Google, instead Google actually asked them why they left.  I think we can safely say that many of the points raised in this collection of responses contain valid issues.

By far the most common complaint is with regard to the recruitment process.  It apparently takes forever. It obviously never stopped these people from joining, but left a lasting impression.  However, if they could get over this hang-up with the recruitment process, what really is the problem?

First, as much as people like to pretend that it doesn’t matter, money plays its part. This seems especially relevant to the ex-Microsoft employees.  These employees seemed to justify the money drop experienced when moving from Microsoft to Google as being “worth it” to work in a “Googly” culture – where Googly tends to translate into FUN.  It seems strange that Google does not have similar pay scales to Microsoft, as they are direct competitors on this front. This may become more of an issue for Google if it appears that their Googly culture is in recession.

Another point that popped up on more than one occasion was management. This is always an easy shot though let’s face it, but it was reiterated by enough people to take a look. My initial impression is that there exists the typical competitive race for promotions (as in looking good, not necessarily doing good), this always leaves certain people unhappy, myself included, it always brings out the worst in people.  I’m genuinely surprised and sad that this sort of behaviour has seeped its way into Google, and it seems the inevitable outcome of a standard management hierarchy in large corporations. Will we never learn anything from Gore’s “Self-management and the flattened hierarchy“? It seems not.

So, is it too soon to say that Google may be losing its highly valued culture? Such a shift can surely only play into the hands of Microsoft, with no difference in culture, and higher salaries, it seems like a no brainer for the top candidates.

My own personal opinion of Google (as an employer) has diminished somewhat after reading the aforementioned article – whose contents must present itself as a PR nightmare for Google. I have maintained (indirectly) for quite some time now that people will only accept smaller salaries if the environment is FUN to work.  Fun seems harder to maintain though as a company grows, and becomes filled with those with glittering ambitions for their own career. Unfortunately the ethos of working together to obtain mutual reward seems sort of out of place in the new millennium. I suspect even this recession, or a prolonged depression, will not stifle the greed of those that are selfish and do not care.

Observations Google, jobs, Management, Microsoft

Back in ancient times and right up until relatively recently (mid 1400s) scribes were used to copy important documents for kings, queens and other nobility.  It’s hard to imagine that most people couldn’t write back then, and I suspect (but can’t find any hard facts) that many many people still had difficulties writing until the beginning of the 1900s.

However, the job of a scribe became almost redundant overnight with the invention of moveable type. At this point we began to see a power shift, as documents were easily copied and translated, and distributed to the masses.  Obviously there was still the hurdle of learning to read, but now many important documents were available to more than just a handful of people – prior to this reading such documents was limited to the nobility and the clergy.

Moveable type was the most popular form of distributing documents and information right up to the modern day. However, with the advent of computers and the internet, this has changed for good.

Today we find less and less people reading books, but instead we mindfully overdose ourselves on blogs and social networking sites.  This information exchange only serves to benefit each and every one of us, as now we can observe opinions that are not dependent on the views of an editor whom we share little to nothing in common.

It’s easy to see how jobs have transformed over the centuries, once coveted jobs are now in the hands of “amateurs”; who to their credit provide content that is more pertinent to the interested party.  So where does this leave us as software developers?  How will our roles stand up with the future in mind?

If we think back to what I said earlier, about how not too long ago most people couldn’t even write, and consider that the computer was out of reach, both financially and physically, of most people, but now both these things are the norm in society.  So just as everyone learned to write, is everyone going to learn to program?

OK, you may be thinking that a field like mathematics has been around a long long time, and that not everyone is competent in even basic mathematics.  However, let’s face facts, a general programming task is nowhere near a difficult as even high-school level mathematics. That’s not to say there does not exist difficult computing tasks; in fact I’m hoping to convince you of the opposite.

Is it that crazy to think that one day people will program a computer in the same vein as we read and write English (insert your native tongue here)?  I don’t think so. Programming is not really that difficult (doing it well is as difficult as writing beautifully in English, and that has never stoped people writing, look at me). Just as blogs and the internet pulled down the barrier for each and every one of us to write and be heard, I feel it’s only a matter of time before programming computers becomes something more akin to what many will do in everyday life.

If we look closely the first steps are underway. People are using HTML, CSS and JavaScript as if they were everyday things.  They may be doing them under the veil of certain tools, but the “non-programmers” are programming.  They may not even know they are doing it, and the ability to make more complex applications is only going to get easier.

For example, consider writing a database application for an online bicycle shop using CakePHP (something I have experience of, hence the inclusion). You have to know almost nothing about using a database to create this application. OK, you may say that scaling and optimising these things takes a “professional”, but at the rate we are pushing the technology, this barrier may not be there on 5-10 years time – consider the cloud computing environments as a step in this direction.

What I’m not saying here is that all computing is easy. There are still problems that are difficult to solve and require much much more than simply following a fixed set of instructions. Indeed, this is the domain where us developers must start focusing.

There may be many readers out there that think this is all nonsense and that programming computers is always going to be an elite occupation. Just tell that to the scribes, journalists and the media presenters/organisations, whose occupations have either vanished or are suffering severe contraction. Many of these occupations never seen it coming (or refused to see it coming) and done nothing -  but just remember how quick this actually happened to each group. Do you want to be in the same position?

Observations, programming future of programming, programming, software developers