soledad penadés

During the past three years I've been working in two different environments: big and small companies. Both producing the same kind of final products (corporate applications with web interfaces) have similar problems, and I thought it may be interesting to share them with you so we can find out if there's any solution, and if not, we always can complain and moan about the horrible career we have chosen for our life and how well we would do taking care of green lettuces in a peaceful but lost country farm. So there we go with my appreciations!

About Open Source

• Open Source is good but it is not free Although having access to the source code of something means you can adapt the software at your complete will, it doesn't imply that it will be quicker than writing it from scratch. The Open-* Philosophy is great, brilliant, but contributors come from very different backgrounds and sometimes the quality is not what you would expect. Most of the times, mixing several open source projects under another one results in a funky mix of interfaces, classes and methods, with lots of conversions and patches here and there. That is not good, mainly if you want a robust, well thought code, and also for obvious maintenance reasons.
• Using OS without contributing back to the community sucks You might believe you're ingenious by using Open Source code and saving some money, thus gaining advantage over your competitors, but developers feel bad about doing that. They know they should give something back to the community and feel really dispaired when you strictly forbid it "because it would mean losing your investment".

• The cheapest option is always the most expensive Hiring unexperienced developers at a very cheap salary with the hope that they will come up to date in a couple of months is an utopia. The senior developers will feel stupid having to explain once and once again the basics to someone who must know that, and then will get unmotivated the third time they have to argue why using functions instead of copying and pasting the same code is better, for example.
• Sometimes, employees know more than the employer Face it. You may have lots of experience from ten years ago, you may know how to negociate even with a Demon, but you're not up to date with nowadays technologies. If they discuss any of your decissions, do not try to impose your methods using brute force. It is not an act of rebellion which needs to be dealt with quickly. Just listen to them and learn the most that you can, then think again about your decission.
• Improving the skills Good developers are curious, they love to learn new things. Allowing, and encouraging them to spend work time to find out new techniques and be up to date will not only make them happy and unestressed but that will also reflect in the efficiency of your products.
• Respect the spare time Everybody needs to rest and have a break from work, even if you think that it is superexciting. Making the people stay for half an hour more every day, suggesting to study new things in their commute home, etc, it's not only dishonest but it's also stressing.

• You absolutely need a designer Every interface should be created by a designer. They know where to place things. They are professionals on that. No matter how distinguished and exquisite your graphical skills are, you will never be as good as a real designer. If you can't afford to hire a designer full time, just look for any decent agency and get a good design made for your product. (I could spend hours describing the horrible interfaces I've seen in these three years, all of them consequence of wanting to save some money in the designer area.)
• Good print designers may be horrible web designers Basically, what works in paper may not work in a screen. The style guide of a corporation may be appropiate for printed materials but not for a web product. Unfortunately, there are lots of self-called web designers which create painful html+css layouts, impossible to understand, maintain or modify, so finding a really good web designer may be a tedious task, but will prove to be worth it.
• An interface design is more than a screenshot Good interface design will be based on a style guide. Do not think of an style guide as an arbitrary imposition of rules, think of it as a framework that will help you develop the application, saving time on decissions and not having to fix things which are not consistent later on. It is better to provide the developers with all the elements that they will need for the development: logotypes in the needed sizes, interface elements (bullets, fonts), colours (do not give them a Pantone number, they are not designers and they do not have a Pantone list: give them an HTML hexadecimal code, as that's what they will finally use). By doing so, it's very complicated that they miss anything.

• Developers aren't machines for converting code into money They are people, and they have feelings, and they also notice yours. If you're trying to manipulate them, they will notice. And they will turn angry at that (possibly leaving the company in the most stressful moment).
• Don't try to look smarter than you really are Because good programmers are also good observers, they will notice instantly that you're pretending to be what you're not, and will probably lose respect for you.
• Verbosity produces boredom Being detailed is good. Developers love to hear details about things because it helps them to anticipate what's next, getting a better overview of everything, which is a must for doing a good product. But being too verbose each time you get to talk to them will make them avoid talking to you, because you'll bore them, and they hate boredom. You don't need to revisit every single detail when you're being asked a simple question, nor is there need for explaining the technical implications of using one or another method for whatever to someone which possibly already told you about those technical implications (because he noticed before). Keep it short and they will come back often!
• Keep meetings to a minimum Directly related to the above suggestion!

• Your client might use IE, but the public might not Your client's browser is not the browser that people will use. Do not develop for their browser. Develop for the standards, and you won't get angry calls some years after when (hopefully) bad hacks for IE stop working. Also, developers tend to use Firefox. Telling them to use IE "because that's what the client uses" will turn them into an anger machine, and you don't want that, obviously.
• Your client might be wrong He doesn't neccessarily need that flash intro, for example.

• Users are not idiots It may occur that the interface is confusing them and then they act as idiots. Maybe they have a different logic - not everybody thinks like you. Maybe you didn't test properly in other scenarios and they are getting errors that didn't arise in your environments. But if you refer to them as idiots, the developers will finally believe it, and get unmotivated, because no one likes to work for idiots.