sábado, 19 de julio de 2014

NDC 2014 Oslo: Core software design principles (DRY, YAGNI and SRP+SLAP)

So here we go with one of the greatest talks I went in the conference: Core Software Design Principles by Venkat Subramaniam.



I didn´t know Venkat before the conference (you can blame me) and everybody told me he was a good speaker. I went and it was a lot more than what I expected.
If you want to know more about Venkat I think one of the best ways would be to go reading one of his books:
http://www.amazon.com/Venkat-Subramaniam/e/B001JOS4R2

I went also to his talk Transforming C# into functional programming, samely awesome.

Today I wanted to share with you the highlights of his talk Core Sofware Design Principles, cause it turned out to be the clearest explanation of SOLID and many other principles I´ve ever received.
I wish I could explain it as good as he did.
Maybe you are thinking "I know SOLID, leave me alone". Well, I thought I kew but... what about Liskov substitution (its name doesn´t give it any favour)? Do you know YAGNI, DRY?

If you have been reading about design patterns, code, principles, you´ll probably notice that one of the cornerstones is Simplicity. No matter what you read, simplicity is always the goal. Here you can find a few hints about it: http://codexfun.blogspot.com.es/2014/06/keep-that-simple.html

What I really liked in Venkat´s lecture was the real life examples he put and the passion in his explanations. He also made use of code examples that ease understanding of the concepts so much.

Design Principles

Principles are a set of practices that help us create better quality software, which are found to be effectived for many programmers along the years, if applied in the correct way in the right degree.

We shouldn´t confuse principles with patterns. If we take a pattern and try to apply it to a problem, it may be that we can´t apply it. Nevertheless a principle is something we always strive for so that it offers a bigger value than anything else. A pattern is a specific solution to a specific problem, and the solution is always met by trying to meet some principles. E.g. Strategy pattern solves a problem when a system is prone to change by meeting the Single Responsability Principle.

Nevertheles, principles, as patterns,  offer a common vocabulary to express ideas to communicate each other, so that when you are in technical grooming somebody might say: You can´t do this because, it will break OCP.
We must be careful because we may, as patterns, overuse them.

Venkat told he doesn´t like the term SOLID that many programmers are used to, because there are many other principles that are as important as SOLID.

So let get this party started!

DRY Principle, Don´t Repeat Yourself

Every knowledge in a system must have a single authorative unambigous representation

When we try to follow this principle we must ask the following: where is this piece of knowledge in my code?

Who´s playing the guitar? What if we have a bug in the guitar:D

Imagine we have a system that creates Requisitions. What if in the future we have to change this knowledge to create requistions? If we spread this logic into several places in the code, we would have to change all of these places, making a dupplication effort. And when bugs arise we would have to fix bugs in multiple places.

Imagine we have a web application with several pages. In several of these web pages we have a field called OrderNumber, on which we perform some validations. We should strive to have these validations over OrderNumber in a single place. Because of the same reasons.

DRY is not only about duplication of code, but also about duplication of knowledge.

YAGNI Principle, You Ain´t Gonna Need It

This principle is telling us that something we are coding now, won´t be required at all.
When we are designing a system from scratch we put a lot of different things in place: validations, new data types, generics for better reuse, extensibility mechanism,...
Question is: Do you really need it? If the answer is No, we should postpone the decission until we know it better.

Somebody already invented a lips painting mask, just in case. I don´t think it even works but any girl in the room would better tell:)

Apparently this principle makes Venkat´s mates angry: they took a lot of time to make that generic superb cool class, you better use it!
What he does is that he adds: You Ain´t Gonna Need It + Yet!
Isn´t this cool, we have a way to avoid angry colleagues. Argument is the following: requirements may change, right? So why don´t we postpone the decission to add this generic class for future sprints until we have a better knowledge. It may be that we need it, but we don´t know it YET!
If so, we can track back the history of the project and include this class again.

Bear in mind that most of the extensions and generic component that we add in our code are likely not to be used. Maybe you have experience the following disgusting situation:
-Code reviewer: "This generic interface is cool mate but you have only one concrete implementation."
-Programmer: "Oh, yes, but it is already there, so in one year we could add a second implementaion! Don´t piss me off"

SRP, Single Responsibility Principle

Every piece of code must have ONE purpose, ONE reason. 
One of the best known, in my opinion because of its simple meaningful name, or not? :)

This principle is about Cohesion: things that go together must belong together. If not, they should go separate.

We all have been students and sometimes we didn´t have time to tidy up our room, not gonna blame you if this was your "clothes box":

What if we want to wear our favourite dress for a date with a beautiful girl. It can be tricky, but we can make it, we may use a B-Plan:


Our parents probably tried to teach us how to tidy up our clothes, but it never worked!
We eventually went serious with that girl, we got married... She was a wonderful and tidy girl, our wardrobe became this:


Isn´t this a realm of harmony and peace? Everything in its right place. Awesome. One part for tshirts, one for suits, one for ties,...
Now we have a great advantage: We can find our favourite tshirt very quickly when required!
If we were used to this mess, our girl did a big effort with us to change our mindset because it was much easier to throw things into our box.

Same thing happens in code. We get a task and it is much easier to throw this piece of functionality anywhere in the solution. But we should bear in mind that solving bugs takes more money that adding the code in the beginning. We want to save money and time when it comes to fix something in the future.
If we take discipline and follow SRP, it gets easier and easier, you get a good habit.
We can follow SRP all over our code:

Classes: 
Before this talk I was a lot into applying SRP in classes, because classes are natural representation of a bussiness entity in our software. Some simple rules to apply SRP in classes:
  • Don´t put multiple classes in one file.
  • Classes have to be narrow and focus. E.g. imagine one class with multiple calculations, database operations, communication. This is so unstable, every change in the system will affect this class because it does everything. If we create multiple small focus classes, a reason for a class to change becomes lower.
Methods:
Something stupid from my side was that I hadn´t thought in the importance of SRP in methods. Venkat took quite a bit of time to explain this.
Long methods are a bad idea because:

  • They are hard to read.
  • Hard to test.
  • Hard to reuse: how do you reuse a monsterous method when you need that 10 lines of code in the middle? You can´t and it leads to dupplication of these 10 lines.
  • Hard to maintain, modify and eventually remove if some piece of the method changes.

Please spread this idea: Don´t write long methods. It´s a simple thing to avoid and it leads to a great benefit.
If we write short methods we turn to follow SRP in them.

How long is long? 

Instead of trying to put a number or a size, Venkat gave an example similar to this:

Remember this Kid A mate that is new in your company. Everybody says he writes long methods. You want to check...

-How was your weekend Kid A?
-At 19.00 on Saturday I took my car, drive to Albert Hall using Ring3, arrived to a concert by Radiohead, it was great, they played the full album called as me, Johny Greenwood did a mistake in a song, I drank 6 beers and a few shots so I had to sleep in a park and I couldn´t speak to that girl I like, so on Sunday I had a huge handover....
Ten minutes later...
-Ouch, please stop, TMI. 
-Oh, you told me how was my weekend, what´s up?
-Yeah right, I thought you could explain me how was your weekend without doing the same you do in code. You are the guy that writes long methods, aren´t you?

His answer was too long, he of course violated SRP. We don´t speak to people like this.
We speak to colleagues like this:
-Hi Jose Gonzalez, how was your weekend?
-Well, on Saturday I played in a concert, on Sunday I went to the park.
-Wow a concert! How was that?
-It was great, people liked my new album.

Jose Gonzalez is a SRP guy. He explains in high level of concepts. When we wanted more info about a certain concept, because we prefer music, we follow and ask about his concert.
Maybe another colleague more interested in parks will come and ask Jose about it with more detail.

So please keep this:

We must mention things in one level of abstraction at a time.

This is the so called SLAP principle, Single Level of Abstraction. 
It is also called Compose Method: a method should nicely compose things at a single level of abstraction. If you need more info about a certain abstraction you can go to that method and see the next level of abstraction:

 How_was_your_weekend()
{
       Played_in_concert()
       Went_to_park()
}

Played_in_concert()
{
     Where_was_it()
     Which_songs_did_you_played()
     Duration()
     ....
}

Went_to_park()
{
      Which_park()
      What_did_you_do()
      ...
}

I think this is more than enough for today.
Next day we will follow with TDA (Tell don´t ask), OCP (Open-Close), LSP (Liskov Substitution) and DIP (Dependency Inversion).

Please send me your questions, answers, insults.
I know it´s summer vacation but I´ll throw it..

Keep coding!:D

viernes, 18 de julio de 2014

NDC 2014 Series

Hi there!

Last June I had the pleassure to assist to Norwegian Developers Conference (NDC). It was held in Oslo Spektrum, 2-6 June.
This is one of the things you shouldn´t miss if you like programming, design, technology, agile methodologies and much more.
Oslo Spektrum is a perfect scenario with a big large hall full of stands with lots of mainstream brands, a big stage with music, one book shop, entertainment and good food.


In the sides of this main hall there are 9 stages with different sizes, where 9 parallel talks are held every hour, from 9 am to 5 pm.


The quality of the speakers and topics made it so difficult to choose between talks  so one could simply go to stage #10 and watch every of them in different screens, simply by changing the headphone´s channel.

If you are in this code´s business, this is the kind of experiences that really can change your way to look at things.
You could go to a life changing talk about productivity, an architecture speach held by one of these american big gurus, attend to a talk about a cutting-edge technology or simply let the great Kevlin Henney explain why indentation matters in half an hour.

I know sometimes the problem is the price. I´m checking prices for NDC London 2014 that will take place in December. If you apply now it costs 950 pounds, almost 1200 euros. Ok, it´s a lot for a Junior programmer salary or whatsoever. But if you look at this as an investement it isn´t much.
Be sure that if you go to one of this you´ll be doing a better job and what´s more important you´ll have more fun everyday.


Even though you can´t afford this for any reason, all of the talks are available online in Vimeo.

Here you have the full program:
http://ndcoslo.oktaset.com/agenda

And here there are all of the videos:
http://vimeo.com/ndcoslo

Still, if you are as lazy as me, I will try to do a post with the most interesting talks I went, NDC 2014 Series
I hope you like it. Please send me your feedback.

See you in NDC London 2014?

domingo, 6 de julio de 2014

Being a Junior developer

Hi there!

One of the things I do to take the best of my time is to do things when doing other things. Maybe this is not a good thing, so I don´t want you to take this as an advice:)

But yes, I do run, and while I'm running I will hear some Music I like. But I also hear podcasts, and one of my favourite time span to hear that is while running. I hear programming podcast. I know, I can look like a nerd, but these podcasts are pretty awesome.

Yesterday I was running back home and I took one of the great Scott Hanselman. This is the podcast:
http://hanselminutes.com/427/what-it-really-means-to-be-junior-developer-with-jonathan-barronville

The podcast was a talk between Scott and Jonathan Barronville, a Junior Programmer. Yes, he was proud of being a Junior Programmer.
It was like a revelation for me. I remembered myself some years ago, pretty stressed being a Junior Programmer, I wanted to become a Software Architect in some months.

Why should I be proud of being a Junior Programmer?

Have you experienced that situtation: you are clearly the "junior guy"?
It can be really a stigma, you hate yourself for being that and salary doesn´t help on that.

Jonathan experienced the same situation, and one day he asked himself, why is that happening?
He suddenly noticed that it was more a benefit than a bad thing, it was a great:
-He could learn.
-Being paid for it.
-Yet it was Ok to make mistakes, actually he was expected to make it.

The Senior guy, despite the fact of having an awesome title, it is harder for them to messed up.

What is Experience?

Years, years in the company, years in the technology?
Experience is more what you know and what you have to learn.
Have you ever hear the following: this guy must be a Senior because he has 20 years in the company.

We all know people that have been so many years in a company, maybe 10 years, but they keep on doing the same every year (language, project, technology). That´s the same year 10 different times.

On the other hand, if you have the same 10 years, but you´ve been in 5 different projects, three companies, four frameworks, diverse group of people, failing, it has much more value.
We must focus not only into years of experience, but even more important what have you done in those years.

Making Mistakes 

Ouch, it even hurts to write this word, MISTAKE...



In our industry, mistakes are not seen well.
In my opinion failures are so valuable: it tells that somebody have tried something and learn something while failing.

In our culture we would probably take the following resume very seriously:

Juan Antonio Vicaria, PhD Computer Science, MVP Microsoft, C#, Phyton, JS, Ruby, C++, Erlang. 5 years experience...

Would you think the same about the following?

Juan Antonio Vicaria, 2 years in C# learning from scratch, 2 years trying different JS Frameworks, 1 project that failed because of scope, 1 project failed because of incorrect technology chosen, 1 succesful project.

I would like to be the second Vicaria. I´m going to work so hard to make mistakes when I can.


Embrace Learning

Learning is as important as failing. They are so related because when you are learning something you make mistakes, that´s how you learn.
We should see and understand what people have learnt.
For example we should value not only the number of languages somebody knows, but what he has learnt with them.
"Ok, you have NodeJS in your CV, but tell me what it offers, what have you learnt with it".

We should value people learning new things. Every time we learn a new language, even though you are not using it, you have learnt something. You don´t need to be a master in the language, you just may know that it exists and what kind of problems solves. One day, if needed, you will go and learn it properly for a project.
If we take the example of a famous cooker, in his CV we won´t see that he is able to use 20 different pans, 1000 techniques for preparing meat, 2000 ingredients he knows how to use.
Instead, we should probably see some examples of his best dishes. Knowing techniques to get the very best of every ingredient is much better than just saying, I know 1000 techniques.



A Junior developer is somebody realising there are a number of tools that he needs to learn to do well under different scenarios.

We could be a 20 years experience developer, and suddenly we have to learn Erlang. We are totally new to Functional languages.
Why shouldn´t we accept that we suddenly became Junior Developers? What´s the problem in that?
We were just lucky, because we suddenly are allowed to take our time, go and learn, and fail when learning.

Embrace Not-knowing

Our world is crazy, we have to know ASP, Knockout, Node, Angular, ext, .net, js, sql, mongo, spring, hybertnate, jasmine, nunit, specflow,... I could follow like that forever.

Again, what´s the problem in saying "I DON´T KNOW"?



Imagine we go to a meeting and when somebody suggests SignalR for the next project, we don´t know what it even is.
In our world, any programmer (Junior or Senior) normally would simply don´t say a word. Later he would go to Wikipedia and read the first paragraph of SignalR.
I have done it so many times that I feel ashamed.

Why don´t we go to that meeting and tell "Sorry, I don´t know what is SignalR, seriously buddy I don´t have any idea of what it is. Can you explain me?"
Even if you have 15 years experience, you don´t have to know everything.

Please next time you are in that situation, please go ahead, tell "I don´t know". Ask that question, nobody should look at you badly.
Please if you are the guy that knows, don´t look at them badly. Please go ahead and explain.
I would like to say that to the junior Juan Antonio, please mate, don´t feel bad when asking, you are there to learn.

Specially when a new guy arrives to the company.
Have you seen the typical nerd superb programmer in the company who is the typical don´t-ask-me-questions guy?
Yes, you will go to his place, you are the new programmer in town, he will look at you with an icy sight, telling:
"I would tell a few words, but why on earth have you entered in the company without knowing that, why are you such a moron?".

Please go ahead and get rid off this type of people surrounding you, people that makes you feel so damn for not-knowing.
If you don´t know what I mean please meet Nick Burns, watch this:


We are all learners, we should keep that passion about learning, even if you have 30 years, you should still feel like a junior programmer, feeling that you are getting a new thing everyday, starting fresh every year.
If you are one year experience, if you are a junior programmer surrounded by Nick Burns, please don´t feel bad. Embrace the passion of learning.

Being a Junior developer again


I know a person, he has worked in my company for more than 10 years. He knew everything about the old framework. One day, he felt like he wanted a change and moved to a new project.
Suddenly he was surrounded by young people with more knowledge about the new project.
But he was able to say and ask these questions, he went modeslty and started to learn again. Now he is an architect in his area.

Some years ago I felt so badly being a Junior. I was payed lower than my Nick Burns´ mates, I would literally sit in front of the computer, everyday, feeling like a damn, blaming myself, I would think every 5 minutes when I´m going to stop being a Junior programmer.

One day something change, I stop blaming and complaining about my role, if I had to be there, let´s take the best of everyday. I stop getting stressed about being a Junior, instead focus on learning.
I suddenly became a non-junior programmer without actually thinking on that.


In one month I´ll be starting in a new company. I´m going to be the Junior guy, I´m not going to feel bad for not knowing. Yet, I won´t arrive as a super star. I would like to be able to say: "I don´t know that" "Can I ask you a question?".
I´m looking forward to being again a Junior programmer. Because life is so boring that we have to keep moving ourselves out of the confort zone. Yes, it feels hard in the begining, but isn´t it great when you have faced that and you have learnt something new.

Please let´s go and change our bussiness. We have a long way to go.

Here you can read the full article written by Jonathan Barronville about this:
 https://medium.com/i-m-h-o/what-it-really-means-to-be-a-junior-developer-266acb772b4b

If you don´t know Scott Hanselman, please go now to his blog:
http://www.hanselman.com/
I met Scott in NDC 2014 here in Oslo. He gave a great talk: Fun with Javascript. Fantastic talk:
http://vimeo.com/97454683

Keep coding, keep learning!