Refactor your code

Everyone can write code than can be understood by a machine, but not everyone can write code that can be understood by another human.

In the daily routine of a software developer, is as usual taking part in new developments as maintaining legacy systems. That is why it is very important to ensure that our code is as easy as possible to be read, understood and extended. And in this context refactoring has a key importance.

Refactoring is about improving the quality of our code and it is a task that needs to be applied as a part of deeper process. In this process, the developer usually follows this approach:

  • Writing the code that solves the problem we are facing.
  • Testing the code using automation tests (unit tests, integration tests, etc).
  • Refactor our code ensuring that the tests still pass.

In the previous process, having tests covering our code is a must. Why? Because it is the best way to ensure that the refactoring we are applying has not introduced new bugs in our code.

To read more about refactoring, there is a brilliant book by Martin Fowler. Your can find it here:
http://www.amazon.co.uk/Refactoring-Improving-Design-Existing-Technology/dp/0201485672/ref=sr_1_1?ie=UTF8&qid=1368304237&sr=8-1&keywords=refactoring

Dude, the execution path of this company is as confusing as the script of a soap opera. Yes, maybe it is about time to do some refactoring Jose Armando de los Angeles ;) .

Second lesson in Scrum or How to manage the team whiteboard

A really helpful artifact in Scrum is the whiteboard. The whiteboard is one of the main responses of Scrum to the transparency principle (but not the only one). And why I am saying this? Because, it is the place where the development team will show to the rest of the organization the progress and state of its sprint backlog.

There are several things that can be written down in a whiteboard, but the general structure will be a table with a column for each one of the following states:

  • To do: User stories (and tasks) that make up the sprint backlog.
  • In progress: Stories in which the dev team is working on in this moment.
  • Ready to test: stories that have been worked on, and are ready to be tested.
  • In test: stories that are currently being tested (by members of the development team, usually QA testers).
  • Done: stories that meet the ‘Definition of Done’ agreed by the Scrum team, and consequently, can be accepted by the product owner as done and ready to deliver.

Notice how ideally, QA testes will be responsible for moving the state of the stories from ready to test to done. And they will do that based on the Definition of Done of the team. The Definition of Done could be different across teams, but has to be enough to make a product or a certain feature releasable.

First lesson in Scrum

I have started to read the Scrum Guide which is a sixteen-page long document in which is explained the principals of Scrum.

First of all, Scrum is not a set of guidelines which you’re tightly coupled to, but it’s a framework that tries to drive the teams to follow some rules and advices such as:

  • Transparency
  • Inspection
  • Adaptation

The Scrum framework consists of Scrum Teams and their associated roles, events, artifacts and rules. Each component within the framework serves a specific purpose and is essential to Scrum’s success and usage.

The Scrum Team consists of a group of between three and nine members. There’re some roles that are mandatory like Product Owner, the Development Team and Scrum Master.

The Product Owner is responsible for managing the Product Backlog, which is a list of items (PBI) or user stories that need to be completed to finish the project. A user story can be thought as some kind of use case but with some differences.

The PBIs are ordered by priority which is meant to be used to reflect how important or urgent a piece of work is for the project. The only person responsible for assigning priorities is the Product Owner. These priorities are likely to change along the time. However as soon as the dev team starts to work on a subset of PBIs (this is called Sprint Backlog) no one should change them. Everyone in a organization has to be able to access the Product Backlog but without changing it.

Regarding the Sprint Backlog, the best way to make it visible to the whole organization is by using a whiteboard and post-its or stickers.

How to decide how many of the top priority PBIs of the Product Backlog are going to make up the Sprint Backlog will depend on how difficult or complex each of the PBIs are. In other words, every PBI has a number of points to reflect the amount of effort that the dev team will have to put on it to implement it.

Design Patterns in a nutshell

I have reached the conclusion that I need to review what I know about Design Patterns. For those of you who actually do not know what they are, it can be said that they are guidelines o solutions we can apply when we face certain design problems in our daily work. They have been proven to work, and they also provide a common vocabulary to share among professionals. In other words, when you say that an Adapter could be the solution to a certain problem, everyone (should) knows what are you talking about and how to implement the solution.

So, if you had not heard about them yet, you can start by reading some really well known references, like the popular ‘Design patterns: elements of reusable object-oriented software‘, written by the Gang of Four back in 1994 (aka GoF).

http://www.amazon.co.uk/Design-patterns-elements-reusable-object-oriented/dp/0201633612/ref=sr_1_1?ie=UTF8&qid=1364162505&sr=8-1

But obviously, the Internet is full of blogs, articles and all kind of materials talking about patterns. As a professional, it is really important that you are able to understand and apply them. It is one of those things that makes the difference between good developers, and low-profile ones.

Ready to go into Oracle?

Easter Holidays have finally come. Time to rest and chill out… Oh wait!

The academic year is being specially long and tough. But finally, now when they are more needed than ever, holidays have finally arrived. This Easter I have planned to rest and shake all the stress away. However, there might be also some moments to work a bit, as usual.

You have said that I am a certain kind of workaholic? Are you talking to me…? ;-)

So the main thing which I want to focus on is trying to prepare some lessons about PL/SQL and Oracle 11g (http://www.oracle.com/technetwork/products/express-edition/overview/index.html). I know that it is a quite old technology, but it is still very important and used by companies, though. And this is about getting students ready to jump into companies successfully. So, anything to declare? :-) In fact, in IT companies is so commonly used as a quite popular programming language like Visual Basic .NET, and it is not far from essentials like Javascript. Take a look at this piece of information:  http://info.bleum.com/blog/bid/142474/Trend-of-PL-SQL

I am very willing and interested in this training Oracle resume, and even more in PL / SQL. So, as soon as my battery would be fully recharged with useless stored procedures in a PL/SQL package, do promise to put examples of my progress just over there, talking about interesting technical terms.

Finally, exciting news for me.  I am glad to announce that I am thinking of adding a new section to my blog in which I would like to talk about the trips I go on. And can you think of a best start than my next holidays in London? I am sure you cannot, because this is a killer. :-P

Enjoy your holidays and have lots of fun! It’s about time! It’s scary, being away from… my PC-job, laptop-job, job-applications and so on, but I know I’ll come back refreshed and ready to work even harder. Hope you’re doing well.

In the brain of Uncle Bob

One thing that thrills me about some big capitals like London is the amount of events that are going on almost every day. It is very easy to get you agenda fully booked of interesting stuff.

For instance, a very close person told me that he had attended a tech talk with Robert C. Martin (aka Uncle Bob). Can you imagine? This is like being really into music and having the stunning opportunity to attend a concert of The Rolling Stones. Hell yeah!

http://www.amazon.com/Robert-C.-Martin/e/B000APG87E
http://en.wikipedia.org/wiki/Robert_Cecil_Martin

In this talk Uncle Bob talked about the evolution of Object Oriented Design from the very begining (the 70s) to nowadays. And he did it based on his experience as a software developer, starting in the late 70s writting programs in assembly language for 8085 computers (64 Kb of memory!). For those of you who would like to see the whole video of his talk, you can go to this link:

http://skillsmatter.com/podcast/agile-testing/in-the-brain-of-uncle-brain

This Thursday I am going to London to spend my Easter holidays there. I wish I had the opportunity to experience such an exciting event like this. Who knows? In London, everything is absolutely possible!

And if not, keep calm, and have a pint!

Keep calm and carry on correcting…!

Are you really interested in looking into what’s going on a current teaching life…? Neither am I ;-)

Stop asking… You would not imagine anything about that, so complicated or intricate as to be hard to understand or deal with… ;-) Come on, trust me. Uffffffffffff!!!

Estimation in Scrum

So, you miss you years at University playing poker with your mates?

Estimation in Scrum has nothing to do with the traditional ways and methods that usually are followed by companies and teams under methodologies like waterfall or RUP. In fact, the whole process of developing software itself is radically different, but today I would like to talk only about tasks estimation.

Usually, how these things are done is following the up-to-bottom approach, in which some managerial role, such as a project manager, told the members of his team:

-”Well guys, this is what we have to do during the next X days/weeks/months. And I think that you will be able to do it all by that time. And obviously, I want high quality, testing, this, that, and this, and more of that, and yes, also much more of this”.

And what it is more, the more amount of time is he planning ahead, the less accurate this forecast is. So, it is clear that something has to change.

So what Scrum says is simple: Who are the ones who are going to do the work? Ok, the development team. So, why don’t we let them to give an estimation? Let’s try it.

Furthermore, the development team won’t be estimating hours of work. Why? Because no one could do it and do it right? It is a pure guess. No matter how much experience you have. In Scrum, we estimate the complexity of a task by giving points. So, if I this that a task is pretty straightforward, I will give it 1 point (for example). On the other hand, if my gut feeling is that I am facing a complex task, I will give it 13 points. This doesn’t mean that it is 13 times more difficult than the first one. It is only a taste. And every member of the team give his estimate at the same time. If they don’t converge, then they have to discuss until the agreement.

In this context, a technique that has been proven very effective is planning poker. In this game, every member of the team has the same cards, with numbers that mean complexity points. After a new item that needs to be done during the next spring has been discussed, and every one undestands it, all the members show his chosen card with the complexity they feel like at the same time. If it is the same, this item is assigned this complexity. If not, the team has to agree.

Playing poker planning is really cool. But I still miss my long hair. Oh, that’s hard stuff!

Unit testing and TDD

So, you are not unit testing your sofware and you want to be called developer. Interesting… :D

Unit testing is a practice which is not new at all. It has been there for the last years. However, my feeling is that it is something that looks awesome in books, everyone states that they know how to unit test software, but in practice, is not always applied, or not in the way it should.

When we discover or are told about a bug in our software, typically one can see lots of developers scanning the code, implementing a fix without paying too much attention to the side effects of this change in other parts of the app, and immediately test the app using the user interface. Obviously, this is WRONG. In contrast, the right approach would be, trying to reproduce the bug with a test, and make it fail. Then fix the code and then re-run the test. The benefits of this approach is that we are protecting ourselves from this bug for the future. If tomorrow we have to change other part, we can run this test and make sure that this bug is not coming back again. And only with a click and in a few seconds!

In conclusion, this is only one of the advantages of using unit testing, but there are a lot. There are dozens of books out there to read and learn how things should be done. To begin with, you can start with this walkthrough about unit testing and TDD in .NET MVC framework:
http://msdn.microsoft.com/en-us/library/ff847525(v=vs.100).aspx

Oh, so you think that writing unit test is working twice. Whatever man… Tell me this when you have to do overtime trying to find out where the bugs are… :P

MySQL and its new boss

MySQL? What happened to you? You used to be cool! This is not you!

These last few days I have installed the admin GUI tool of MySQL for the first time since it belongs to Oracle in order to prepare some lessons related to the databases subject that I currently teach. But now, this tool is called MySQL Workbench, instead of Administrator or Query Browser.

The thing is that my first impression in not very good at all. Especially when talking about usability. Provided that in the past these tools used to be very simple and intuitive, now the new Workbench is a complete administration tool not very comfortable to use starting from the home screen. And my question is, was this necessary? Personally I am totally against complicated or tricky interfaces. It’s so frustrating when one spends a huge amount of time trying to find out where a button is. Come on, make my life easier, dude!

In conclusion, I liked the old MySQL. It was simple and very easy to use. If I need something else, I would deal with Oracle or SQL Server, but not MySQL.

KISS, KISS, Keep it simple, stupid :-)

Subscribe to RSS Feed Follow me on Twitter!
Follow

Get every new post on this blog delivered to your Inbox.

Join other followers: