I recently stumbled upon a blog post at Joel on Software about ‘The Iceberg Secret‘ – put simply, Joel explains that non technical people will judge the completeness and effectiveness of an application on the GUI alone. You can write an amazingly complicated and involving application, put a basic unstyled page as the GUI and it will be assumed to be a very very early instance or to be simply terrible. Similarly, your user interface guy can put together a beautiful page littered with graphics – not linked to anything processing wise – and the project will be assumed to be ‘almost finished’ or at least ‘not far off’.
I have worked for both technical and non technical people, and can say that it’s not only whether or not the app is finished that is judged based on the quality of the UI. A more important factor that is judged is the productivity of the development team. If you are a developer (which you might be if you’re reading this blog), you will know that writing models and controllers is particularly time consuming with little “real time” reward – that is, people who aren’t programmers can’t see and don’t understand the work that you have put in. Sometimes, this can lead to these people thinking that the programmers are doing nothing but twiddle their thumbs and get excited about charsets, or whatever it is programmers do.
Unfortunately I don’t think there is a lot that can be done about this, other than perhaps using these two useful analogies.
- Writing an application is like building a house. The expensive and time consuming part is the groundwork to prepare the site, the digging of the trenches for the foundations, and the laying of those foundations. During this time the client thinks that you’ve just made a big mess and spent lots of their money, and they haven’t got anything resembling a house to show to anybody. Additionally, if the foundations aren’t laid correctly, the reset of the building will be more likely to fail.
- An application is like a car. It doesn’t matter how much time the engineers spend perfecting the handling and power delivery of the vehicle. If it doesn’t look nice, the majority of people won’t like it, and even more people would decline the opportunity to buy it. The engineering team needs to be backed up by a telented designer to make a successful product.
The judgement of quality or completeness of an application makes it difficult as a developer to put together any kind of portfolio. You want your portfolio to *look* good – in full knowledge that people will judge the sites you have built on look and feel over functionality – despite the fact that you are not applying for a designer’s job at all. But quite often the projects that look the prettiest are the most mundane and simple in terms of technology behind the scenes. In addition to this, it’s rare (but not impossible) that you find an interviewer who is genuinely interested or excited by the way that you have achieved things technically, so talking through how you fully integrated your web application with Microsoft Sharepoint won’t interest them. After all, all those months of development and there’s nothing fancy to see, only an “Update Website from Sharepoint” button in the web app’s control panel. Really, it took 3 months to add that button? I have a cousin in London who can do that kind of thing in an hour or two.