What a long, strange journey this will be...

Do you know what I really like?

Scala.

I’m really loving this language for a number of reasons, and I’ll probably babble a bit about some features here in a couple of posts… 

Coming from a Java background, I’ve still been able to dabble a bit in other languages, especially Python (which I find to be an absolutely brilliant language), but still, there’s the problem of integration and a learning curve that is somewhat steep until you can claim being able to code in a truly pythonic fashion.

Now, in Scala, there’s also a learning curve and quite a paradigm shift to a more functional approach to programming (at least if you’re like me and haven’t had much experience with functional languages since college). 

Since Scala is much less verbose then Java and it integrates really, really well, it’s pretty easy to start coding right away and even using it on current projects… I for one have been successfully using it to code all my Unit Tests. 

Just because the actual code needs to be verbose, doesn’t mean the tests also need to be!

I’ll try and follow this small “rant” with some features I really like about the language (examples and all). At least I’ll have a place to look up some patterns when I need them :D

When is done actually done

Most developers simply love writing code and figuring out how to make something work, unfortunately, that sometimes makes us a little to eager to say something is “done”.
When your work is really done actually depends on the context of what you’re working on, let’s look at a couple of examples… 
Is it a school project?
It’s done when the output is what’s expected, you used the right algorithms, and the code isn’t too messy… or whenever the date is due. 
Are you just hacking something up to try a new language?
It’s always done really, since you mostly just make it up as you go, however it ends up is fine, the purpose was to learn something right?  (Yes, I have about 5 or 6 barely started projects right now, one in Scala, 2 in Ruby on Rails and 2 in Django…)
Are you working on a feature that someone else is actually going to use?
Well… then it probably won’t be done when you first think it is, and the biggest mistake you can make is to say it is.
You code up a feature to plug into a big and important project, you use the main functionalities and they actually work, everything is stored nice and safely in the database, and everyone is happy, right? It’s done! Except it’s not… after you get it to work, there are several questions you must ask yourself before telling anyone (not your boss, and especially not your client), that it’s done.
If you’re part of a bigger team, does it actually work together with the remainder of the product? Make sure you at least test it as a user will use the product, and not just the part you built. Perhaps the web page with your feature looks great when you’re testing it, but it might look weird to a user coming from the homepage and passing 2 or 3 other pages on the way to see it actually doesn’t keep a consistent aspect with the rest of the application… ups.
Did you test everything? I mean, clicked all the buttons, filled up a good amount of combinations in the fields, tried to do stupid things like leaving mandatory fields blank and writing some gibberish in numeric fields? No? Then go do that please… users will behave however they feel like it, and if your product has a user manual, they won’t read it, so it’s your job to make sure that the feature you’re building can take the punishment.
I think the most important one to remember is… never tell anyone it’s done, if it’s NOT! These kind of conversations usually go something like this:

Manager: So, how is the feature X going? Is it done?
Developer: Yeah! Done deal, tested it just a while ago.
Manager: Great, let’s see that… *click click*… hmm, this isn’t working, this isn’t what’s supposed to show up…
Developer: Yeah, I mean… all the logic is there, now I just have to get the right results.
Manager: Right… so… it’s not done.

Please don’t do this. You’re boycotting yourself and, if you pull this off a couple of times in a row, making sure that your manager/client/whoever you report to, won’t believe when you tell him that something is actually done, even if it is. It’s no use delivering something one day before the due date if you’ll need two more days to actually finish it.

Under promise, over deliver, make yourself reliable.

Whatever your particular context may be, make sure that it’s either done, or that you’re honest about it!

How I learned to stop worrying and love usability

Some developers hate designers. Some designers hate developers. I can’t say I ever belonged to the first category but I certainly thought of design more of a prettying up the result than an essential part of the process to build a quality product.

I’ve always loved building stuff. This is probably one of the most common traits among engineers, there are few of us who can say LEGO’s weren’t in the top of their favorite toys.

Even when I was a boy, I was always trying to build for performance, not looks. I remember building cars out of LEGO and crash testing them to see what builds were the fastest and the toughest (the ones among you who know me and are prone to psychological analysis are probably thinking this explains a lot about me…). I used the same approach with LEGO buildings, I tried to build them so that I could stack as many floors as possible, no matter how little it actually resembled a building in the end.

For a long time in my path as a developer (I’ve been working for four years now so I guess long here is a relative term), I’ve always considering myself more skilled building the backend of a system instead of anything users would actually need to look at, like always, I build for performance, taking a good deal of care to make my work elegant and understandable to those who would pick it up after me. 

When I happened to face the task of choosing, for instance, the colors for a particular webpage, I couldn’t make it look good to save my life, so I always tried to stick with what I was good at, and let others worry about how it’ll look to the user.  

When I started reading about Usability and UX (can’t remember exactly when it happened to be honest), there was something there that made a lot of sense to me: It wasn’t about making something look prettier, it was about making it better. 

Providing good usability helps all your users perform better when using your product, and it’s not enough to have that method return the right results in under a second if the user spends 2 minutes trying to figure out what option he needs to click. When something that you build is used by a couple million people, the overall time spent looking for the right options due to poor usability quickly rises to staggering amounts of time (this number isn’t really statistically relevant, but hey, still a nice figure to keep in mind). Build to help users perform good in what they have to do. 

As for colors and eye candy… well, I still can’t pick them to save my life, but a visual appealing design is not only perceived as more usable and robust, it also shows you’ve gone that extra mile to make sure the user has an overall pleasant experience when using what you built.

This post is a bit confusing by my own standards, but if I took any longer writing it, it would probably just end up lost and half-written forever, so, please excuse me if you find the ideas to be a bit inconsistent, I’ll do my best to provide you with a better experience next time ;)

Thanks for sticking around! :D

Specs? Ideas? Features?

Well, I’ve promised to rant about my feelings on specifications versus letting ideas flow when designing or developing a project.

So far I’ve worked mostly on traditional software development, and even “worse”, consulting. In this scenario you really don’t want to go up to a client and say “Hey, you know Mr. Company Ten Times Our Size, I haven’t really written down any specification that you can actually look at, but I have this great gut feeling, and I’ve decided to… you know, see where this leads us!” Something like this would end pretty much in disaster.

In a more formal context of software development, it’s hard to gain a client’s trust without showing him some hard proof (usually in printable format), that you ARE working to solve his problems, and that you actually understand what he wants. On the other hand, I feel that sometimes the job of writing and maintaining all this specifications can be a truly daunting task. I usually see one of two things happen:

1. You specify your heart out, start coding away, and then something in the requirements changes (and yes, some critical requirements always change), but the deadline stays the same… so there go the specifications on their way to outdatedness.
2. Requirements change so much, that you end up doing most of the documentation after the project is done, and that turns specification into a kind of novel that recounts your mighty programming deeds. Not exactly useful for the developers, right?

See how I don’t really offer many solutions? Yeah, that’s the ranting nature of the post. Although I’ve been thinking that maybe one needs to embrace that the client must approve some nicely written business-language document just so he knows we’re on the same page, and developers should use something else entirely. What? Whatever works for your team… XP, Pair Programming, Post-it’s on the wall, RUP, you name it.

If, on the other hand, you’re not really catering for a set of stakeholders, and want to do some project either to tickle your own fancy or something you want to throw on the market in the future, formal specifications might just be the way to keep you from making something great.

Let me elaborate on that…

I’m a firm believer that no one likes doing stuff just to throw away. When you take the time to specify from top to bottom what you intend to do before you actually start doing it, you’re making it harder on yourself to try out alternatives, no matter how absurd or small in comparison they might look at first.

Since very few products actually end up being exactly what one first imagined, I believe you shouldn’t really take the time to start writing up use cases and data dictionaries until you’ve explored all the ideas that come to your mind.

I’m a bit old school so, my personal favourite is taking a pad (a paper one, not an “i”), and sketching up the application that I imagine, thinking about what would be the main features, how would it interact with users, and what extra stuff could I put in there. Every once in a while, I get a moment when I think: “Damn! This feature would be.. awesome! This could be the whole concept of the site!”, and that is totally worth the mental and sketching ramblings involved.

I hope that in some time, I’ll be able to share with you guys one of those ideas ;).

So, as a wrap up (this really got longer than I expected!), the main point I’m trying to make is… sketch, specify, draw, discuss, do anything that works for you, but don’t get trapped in formalisms if that’ll mean that you won’t be exploring other alternatives (even vague, long-shot ones) that come to your mind because it’ll be too hard (or too damn boring), to reflect that in some specification.

Thanks for reading this far! And please let me know your thoughts on the subject, really looking forward to hear/read your opinion!

Houston, we have… started building a space shuttle…

Here we go!

Hey everyone, my name is Pedro and you’re witnessing my attempt at creating a blog that I will actually update!

Some of you may be familiar with my other blog, Ravens Of Dispersion, my first attempt at blogging that ended up being a bit neglected (those among you who can read Portuguese are more than welcome to visit it, one never knows when something new is gonna pop out).

Since I’ve set my mind on learning more on Web Development and UX, I’ve been brewing some ideas on a website I intend to build in whatever spare time I can concoct as a way of honing up my HTML5, CSS3, RoR, JQuery and whatnot skills.

I’ll try, to the best of my abilities, to keep you guys posted on my findings and stumbles while exploring worlds outside Java, Swing and the likes.

I’ll tweet any updates, but check in any time =) I can almost certainly guarantee some good laughs on my expense as I try to figure out all this stuff.

Thank you for reading, and remember drop a line!