soledad penadés

repeat 4[fd 100 rt 90]

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".

About the skills

• 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.

About the interface

• 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.

About treating people

• 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!

About your clients

• 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.

About the users

• 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.

Can't really think of something else now. Feel free to add whatever you are missing in the comments!

We decided to start using database sessions instead of the usual php storage method, just to check if that would fix the extremely annoying problem of cakephp completely ignoring the maximum session time settings (no matter what setting did it have, it always logs out people after 20 minutes).

So seems that it worked, people could be inactive for a while and after that they didn't find a "You've been logged out" message. But it revealed a new problem: each requestAction was forcing the creation of a new Session object. And each time it is made, it generates like 3 or 4 queries. Which absolutely gave me the creeps when I saw the queries list!

I knew about the potential bad performance of requestAction, I had been warned, but I decided to use it for a couple of "blocks" because I couldn't believe it was going to perform so badly. I could cope with creating a new Dispatcher for handling the request, but those repeated accesses to Session objects are just plain terrible.

I'm impressed no one has noticed it already. It could be solved using a Singleton approach, just as they do with the ConnectionManager. It also could use some kind of cache since all the session functions are in cakephp's domain when you use the database session handler, so why does it need to query the database to retrieve something that was already retrieved 20 milliseconds again?

I finally removed all the calls to requestAction (by creating an instance of the model which was called by the controller and asking it the values directly, etc) and did a pseudo-cache of the session data in my code, and minimised as much as possible the calls to Session->read. While this is code optimised, it is not readability-optimised. It hurts my eyes to see this structure, it goes against nature and against MVC and against something else I can't recall now. Endless pain and agony! ARRGHH!

So there goes the cakephp + phpbb integration - just commited the files to Subversion and uploaded a tgz package for the lazy ones, some hours ago.

And I don't know if there's expectation about the project or maybe it's just a malfunction in the stats system, but somehow it was one of the most active projects this week. How can it be possible if it was approved two days ago? But hey, it's nice anyway…

It's been a very busy week and it doesn't seem to go down, but surprisingly for most people, I quite like the feeling of being busy, since it doesn't allow you to spend the time procrastinating and thinking about the divine wonders of the Things That I Would Do If…

Among other things, past week mr.doob and me went to the London Flash Platform Users Group Meeting, or shortly lfpug meeting. It was very interesting and I went back home willing to get there soon to be able to download and install adobe flex builder 2 in my mac, as it had just been released that very day and was fresh and risky, as any beta version in this world :)

But I finally installed it yesterday and got almost aslept when trying to compile my simple "hello world" test. Or maybe I was already getting aslept and I thought it was because of flex builder, I don't know. I'll have a look at it later when I sort out more urgent things, I suppose…

We also got escena.org v2 in a usable status (or that I think), when I finally fixed the issues with the Spotlight section (thanks to a trace's suggestion, must recognise). I haven't talked here about the site yet because it doesn't have all the features we've planned for it, but will do when it's in a more advanced status. In any case it seems promising :-)

And in a different topic, just registered on Thursday for my first cakeforge project: cakephpbb, which aims to provide a way of integrating a cakephp application with a phpbb forum. It's something terribly simple, and in fact it has not entirely been developed by me, since it's a result of the collaboration of several people (more of a mash up than anything else). But I've been testing it and already fixed a couple of bugs, and I'm going to provide the documentation for it.

The project was approved yesterday but I won't add any file until monday or tuesday, when I finish the docs (otherwise nobody will be able to use it and it will be a useless project) and get to understand how the cakeforge backend works.

There's more interesting stuff coming in but can't be disclosed yet so you'll have to remain intrigued for a bit more… hope you can stand it :-P

I came across this quote from an article by Bruce Eckel quite recently:
Bruce Eckel on python vs c/c++ indentation:

Let's throw away those curly braces — indentation already has meaning to the human mind, so we'll use that to indicate scope, instead.

After all the fuss with pascal, c++ and then python and its completely absence of braces, it's quite cool to find such a simple yet convincing reason. I think he's absolutely right, when I read the sentence I suddenly got aware of how often we use instinctively indentation to indicate hierarchies. A quick example could be todo.txt's, where in absence of real bullets you can write things like this:

Very important tasks
————————
- Task 1
- Task 2

And when hand writing these lists (i.e. with a real ballpen) we automatically indent the list items. At least I do!

This brings me to something that I had been thinking about too, the expressivity of a language, and more specifically, the expressivity of ruby. When you're learning ruby (such as me), and are faced with the fact that you can write things such as

do
[...]
until a=1

or also

do until a=1
[...]
end

Or

if something
[...]
end

in contrast to

unless not something
[...]
end

then you can have two reactions. There's the first one which will say "this is a horrible and confusing practice and that doesn't help anybody which is learning". And then there's the second reaction which is "well, the brain is not always thinking like a computer". Sometimes you're thinking aloud and may say: we'll do this and this and this until something happens (case A). And sometimes you say until something happens we will do this and this (case B). Normally you have to force your brain to work in just one manner, which somehow restricts your possibilities.
I believe it is this flexibility which you can't find in traditional programming languages (or new languages which inherited traditions) one of the key reasons for the success of python or ruby, because they are quite immediate.

(The irony is when one combines ruby's flexibility with rails' convention over configuration - like two opposite worlds handshaking!)

So what do you think? do you feel comfortable with C++'s-curly-braces-mania? do you think lax syntaxes are bad for learning to code because it makes lazy programmers - kind of too far away and unaware of the computer's internals?