A big wow!

So, the big wow is that I just rediscovered that I have a blog and can use it to post some of my recent crap. Oh.. and it seems like Google updated blogger.com UI, editors and it even looks nice!

Anyhow, I have nothing special to blog about today. OK. Maybe one thing, enjoy your life people, seriously!

You may find more charts like this one at http://chartporn.org/ (btw. great domain name)

Hero who will never be forgotten

Today is a sad day. Steve Jobs passed away. He is and always will be an inspiration to me.

Just passed the DKIM

Just one very short comment: I hate email!!!! (and anything related to it)

But now I am able to send some! ;-)

==========================================================
Summary of Results
==========================================================
SPF check:          pass
DomainKeys check:   neutral
DKIM check:         pass
DKIM check:         pass
Sender-ID check:    pass
SpamAssassin check: ham

Can your software do that good? Send an email to check-auth@verifier.port25.com and see for yourself.

Not sure what I'm talking about? See this: http://www.codinghorror.com/blog/2010/04/so-youd-like-to-send-some-email-through-code.html

SOLID by Uncle Bob

I've spend a couple of minutes today on listening to the Hanselminutes podcast about SOLID principles. The principles presented and explained by Uncle Bob himself is something you totally need to hear if you're any kind of software developer.

It's really good stuff so make sure to take a couple minutes to relax and listen the podcast. It's here: http://www.hanselminutes.com/default.aspx?showID=163

I also summarized them quickly for future reference (but you may like the Wikipedia version better):

• S (Single Responsibility) - Class and a method should have exactly one reason to change
  
• O – Open-Close Principle - Module open for extension, closed for modification. Polymorphism. We use interfaces, extend functionality by using different implementations of that interface. We can add new features by adding new code, not modifying core of the application. Principle of attitude ;-)
  
• L – Liskov substitution principle - The user of the interface should not be surprised by the implementation he's using. If you drive Chevrolet you should not be surprised by driving the VW. Square and Rectangle dilemma. No relationship between them. They are both a Shape, but in code, Square is not a Rectangle! (think about setHeight method.)
  
• I – Interface segregation principle - Applies to very fat classes, classes that have hundreds of methods and many many clients. Populations of clients that use subsets of the methods of this class. Some of the clients use couple of methods there, the other clients use couple of methods somewhere else. If a signature of one of that methods changes, then you need to recompile the class for all the clients, even that ones who are not affected by the change. You don’t want to depend on something you don’t use.
  
• D – Dependency Inversion Principle - Depend only at things that are abstract! Don’t depend at anything concrete, anything!!!! Never touch anything concrete! (In reality of course that never happens.. but there is a rule. The rule is that only those who are volatile can ignore the principle a bit. “The things that change frequently are volatile”, e.g. Main function. You need to instantiate come stuff there... but then depend only on abstractions!)
  

Say one big NO to all Office applications

Office like software is probably the most destructive, demotivating, demoralizing and unproductive tool ever used for documenting software projects. I get sick each time somebody asks me to edit some specification, design document, requirements, etc. It makes me go crazy when I need to find that documents somewhere on the file system or (as people here call it) a "global" share.

The days when companies were able to manage documentation written that way are long time gone. But why do we still do that? Come on, how crazy and irresponsible is that?

In the past (as I was told by couple of my older fellow colleagues) developers used to write their code and store it on an ftp server so that the other coders could take a look at the changes and continue with their updates. This meant conflicts, errors, inconsistency and other kind of bullshit making the released product a complete bullshit. People managed to solve this problem with version control systems and the nightmare was over.

The problem with documents is that they are not code and not being code has a lot of disadvantages these days.

First of all, there is no IDE which can help you find your stuff in seconds. There is no syntax highlighting, no auto-complete, no integrated API. The docs are also (in most cases) extremely long, specifically structured, contain lots of formatting errors, open slowly, contain useless information and the last but most important.. they are stored as files (one or more) and you never know where to put them when you're finished with the content.

C:\Documents\Hmm...
or maybe
C:\Documents and ...\..\My Documents\Hmm..
aaah... there is this share
\\someserver\Docs\... uppss... no, it does not quite fit here

Some companies use LiveLink (for document versioning) but you don't want to see the screenshot of the directory structure that our fellow managers have build. Maybe I am too dumb for that but I simply can't find anything there!

If you have a large project which requires documentation (e.g. medical apps do) you will be scrued very quickly if you don't find a good solution for this problems. Thousands of documents which are hard/impossible to find, nobody ever reads them or cares about, edits them only when it's a must. You end up with thousands of tools which are supposed to help you manage all that crap but what the tools do is make it even more complicated and confusing. Be careful, this may also lead to high peeks on your employee burndown chart (and the most precious employees will burn down first!).

So what to do to finally drop that "standard" document writing/managing crap? People often need to share a *.doc or *.pdf with others, don't they?

Yes they do, but first of all... think... think more... and more? Go on the net... read, think more... get interested in this subject and do not accept with status quo! Got it?

I'll give you the solution which has proven to be extremely successful for me. Get yourself a professional Wiki. I don't mean a TFS wiki (which is CRAP), or a 10kb wiki engine that you can start on your localhost. I mean A PROFESSIONAL WIKI!

Now what can a professional wiki do for you?

1. It can manage you users so that each user:




• has his personal account where he can put his private stuff


• can edit, comment on, review documents (his changes will be visible in th history)


• can blog (yes! blog) about the stuff that he e.g. just discovered, etc.


• has a photo and personality on the wiki


• can communicate directly via Wiki's web interface




2. It can manage your documents so that:




• the documents/wikis are searchable


• the documents are easily editable and accessible


• the documents have common structure (templating)


• the documents can be exported to DOC or PDF


• the documents reference the issues in ISSUE management app


• the documents reference the requirements in the requirement management system


• the documents can be easily versioned


• the documents can handle images, movies and media well


• the documents can contain tables, colors, quotes, code samples, charts, sketches, etc.




3. It can manage your projects!


4. Improves all the time!

Sounds non-realistic? Well, go on Google, type "Confluence" and see for yourself.



I personally LOVE this product. Atlassian did an extremely good job with their wiki and the book they have published. At the moment it is the tool of my choice for the project that I work on and I am more then happy to use it. It's actually fun to use it which is even cooler! So, say NO to Office apps!

Three displays... pure luxury!

I just came back from my holidays and there it is, my third display waiting for me to power it up! Yes, probably as the first in the office I got to work with 3 monitors on the daily basis to proove the legendary "increase in efficiency when using more desktop space" concept.

Well, the setup itself was a bit tricky since I needed to get a special graphic card and a special adapter for one of my displays. Currently ATI supports three or more monitors with their FirePro graphic cards and Eyefinity technology. I ordered FirePro V4800 (the very basic and realatively cheap one) for my purposes. This professional card provides 2 DisplayPorts and 1 DVI port that can be used to plug-in 3 displays. But wath out, there is a trick! In order to enjoy your desktop on 3 screens, you would need at least one monitor with DiplayPort input. If you don't have one then there is an option to buy an expensive (~90-100EUR) active DisplayPort to DVI adapter for you VGA or DVI display. Since at my company they get crappy displays by default, I was forced to get one of those adapters for my setup. It works perfectly.. but it is just an uncecessary additional cost you would want to avoid when possible.

It's to early to say anything about my "performace imporvements" but I already feel great about having my development env in the center, docs on the left side and build results on the right ;-)

Do you speak the "programmer's language" well?

When you speak your language you usually do not ask yourself if you use it properly, what are it's strength and weakness or if you speak it better or worse than the other people. You simply use the words you know to communicate something. The communication may be faster or slower (read "more efficient" or "less efficient) independent of the communication medium. One may be able to use a rich dictionary to pass the same message using just a few properly put, sophisticated words. The other would describe the same thing with simple words. It would just take more time. Talking is natural to us and being faster or more sophisticated sometimes does not mean better. Why not? The problem with the "smart" speaker may be that there will be not to many listeners who will be able to understand him. It all depends on the environment you are in.

Now imagine what happens when a PhD. in whatever subject is put in a room with a person who did not even finish a primary school. Are they able to communicate? Well... Yes. Kind of. The problem is that the PhD. guy will use 5% of his communication skills, start building long sentences of simple words just to be explain the other guy some stuff that seems basic to him. I think you already know where I am going... :-)



The programmers are very much like usual people who instead of "speaking" the "normal, common language", "speak" programming languages, design patterns, recent technologies and some other funky stuff. (Well, at least the real programmers do.). We all know that programmers who know "the sophisticated words" can be much more efficient then those who "speak" the basics. That is mostly the reason why large companies try to hunt down the best to work for them. The problem with programmers however is that it's not that easy to verify their "spoken" skills. To do it correctly, the recruiter must actually be able to speak "the programmer's language" on at least the "considered as minimum of the best need to have" level. Why? Call back the PhD and primary school guy conversation. Accidental addition of a poorly skilled guy to your team of professionals, may (and will) lead to terrifying results. The overall team performance will go down because the communication between the developers will have a bottleneck. In the end paying big money for your experts will make no sense at all since their efficiency will be limited by other group members. The more "average" people are add, the worse the performance is. In the end the company would be better of hiring cheaper developers, as this would not make any difference for the project performance.



Just to illustrate this; imagine a group of developers who all know what a strategy pattern is. Since it's definition is obvious to them, they simply say, "we use the strategy pattern here, and we will use it also there". A guy who does not know what this term means will have no idea of what are they actually talking about.. and thus, can not contribute to the conversation. Asking for explanation is correct but.. it reduces the groups performance. Now instead of simply saying the "strategy pattern" they will need to explain the poor guy what it is what they actually mean step-by-step. Looks like unnecessary effort to me.

Now, why am I writing about all this well known stuff? It's actually very important to me :-) One of the hints that I'll try to keep in my mind at all times is to make sure I work with great people only! They are the source of the success, nothing else. Motivated, educated and experienced freaks who feel like they want to build something great. Get them, set the free and let them build together!

B.t.w. Today I learned that knowing "the language" good does not necessarily mean the ability of using it to "discus". You know... even if you knew all the names of the European poisonous mushrooms you would not be able to really discuss about them, right? This is however another subject. For now, just make sure your people know well "the thing" they are building. The fact that they know "how to build" does not mean that they are also able to use this skill to "understand and discuss about" whatever YOU are building. Know that they want to build it too!