| programming philosophy |
| Written by Frank Schlözer |
|
Why a programming philosophy? And what the heck is a programming philosophy? Well, as a programmer you go a long way with lots of obstacles on the way. You learn a lot of things you never heard about at university and learn from your mistakes. A programming philosophy is pretty much 'learning from mistakes'. As a freelance programmer, programs are my specialty and expertise. My ambition is to achieve excellence, no more, no less. Often, there are also external problems like 'last-minute-changes', that the customer desires. But overall, the program should be as perfect as possible. To get to such a degree, i personally think that a program should be...
User friendliness is most important! One should always implement the k.i.s.s. principle - keep it simple and straightforward! Every user is a 'dummy' - i don't mean that in an arrogant way. Every user first has to learn the interface and work flow! Unnecessary hints and overcrowded menus disrupt the work flow and cost time, nerves and money! There is nothing more annoying than repetitive tasks or unnecessary disruptions! That's why the GUI, colors, visualization of the information, the work flow, overall: the user friendliness, has to be thoroughly thought through.
A program should be well-structured and programmed in a clean fashion. To achieve that, programs must contain understandable variable names, a clear and understandable breakdown of huge algorithms into small algorithms with clear interfaces. In addition, the program should be well-commented and documented. The program should be easy to extend and modular. All of this can only be implemented, if the program is thoroughly thought through in advance by project planning software. What classes are necessary? Which interfaces are being used? What technology best fits the task? To achieve excellence, the planning phase is of key importance. People say, that a good program needs 90% concept and planning and only 10% actual implementation time. In that sense, every idea in the planning phase should be archived. Ideas and concepts should be visualized through UML-diagrams and outlines of database relationships, for example. In addition, a project diary is very practical where milestones can be inserted. That way, the programmer and the customer both have an overview where the project is headed and what to expect in terms of duration and costs. I use a project management software on this website which is available for customers.
For the client, programming is a little bit like 'rocket science'. The client wants a certain problem solved and doesn't understand the technical background. That's why communication is of key importance; especially, to avoid misunderstandings. The client can't measure the complexity of a retroactive change, even if it sounds very trivial at first. That's why a specification sheet should always be acquired. The client now knows exactly what he gets and the programmer knows exactly what to implement into the program. Despite of that, it's still sometimes frustrating for the client, when the project is in an uncertain state. That's why the client should be able to have access to the project status through project management software. |
| Last Updated ( Tuesday, 15 June 2010 15:00 ) |
© 2012 schloezer.net




