Buenas,

care that you I will not go into whether AGILE, SCRUM or the death of the Waterfall model. Today I’m going to something more basic:

We do use methodologies during the software development process?

Do not you like the phrase? then to see if this you think more appropriate

Is why recommended to implement good practices during the software development process?

Do you still like it? I play with the last

You do make software and work in mode Ninja, following only your instinct and reacting to changes as they arise: as… die between terrible suffering!!

I hope that after this introduction has been able to explain the concept: call them methodologies, good practices or in some other way; everyone follows a set of rules when developing software. The initial question is why we do this, and the answer is more than obvious

To reduce the risk in our projects

or if you like more

To have more predictive results that work

It seems simple no? For you to know that more than 50 years have passed since one realized this and formalized it. First created the processes, which were responsible for defining the way in which it should work. The good thing about the processes is that they were 100% measurable. It was very easy to say that as we have defined it to this task on these bases, then it should take 6 months. If everyone respected those processes because the results were highly predictable.

But of course, people are quite unpredictable beings; and both from the side of the customer and the programmers were constantly changes. That is why, a couple of cracks came together and created the manifesto agile; people on processes, response to the change tracking, etc. We are going that you know already…

And again, behind all this had one more than simple reason: to be able to predict the results and be consistent with what a person or a team can do. So now you know, if you ever ask yourself why a team works with a set of rules, a methodology, best practices or the name of fashion, as it is likely to be to improve the output of the team and to be more predictable (among other things)

Clarification: care! that that doesn’t mean that a team working under these premises that do not serve absolutely anything, those cases already know how to fix it: pain!

And close one of Dilbert gift

Saludos @ Home

El Bruno

Buenas,

Today’s post starts with a statement:

HOUSE is a genius

One can refute me that all chapters are the same, something like this:

1. Patient X has unknown disease
2. Give it to House you don’t want to see and accept it reluctantly
3. Patient X creates a link with one of the assistants of House
4. House skips rules to see that kind of disease the patient
5. Team crap it, almost are charged to the patient
6. To House a good of their bosses drop
7. In a moment of inspiration, House da with disease

… and always, or almost always, by the way is ruled out Lupus or autoimmune disease.

With this summary you’ve saved to see the 8 seasons of House . However the best that has House, is that throughout the entire series, the protagonist has a nasty / Host which has made to let go a few phrases that are pure wisdom. An excellent example and of which my favorite is:

Women are never wrong, even when they are wrong, there comes a time of discussion in which surprisingly return to reason.

As that, the 3rd chapter of the first season is titled ” “ Completo de Occam Razor “, which translated into spanglish is something like “ Ockham’s razor . Ockham’s Razor is a principle of makes a pile of years (14th century) that says something like this:

In equal, the simplest explanation is usually the correct.

This is pure wisdom, and common sense to the square. When you work in computer science and issues you face every day, you end up realizing that this is a truth for framing. But of course, as in all truth to frame, should take into account the context of each claim.

Today I’m very graphic, so here is a clear example:

It is clear not?, I hope that Yes, the simplest statements also tend to be correct.

And now if we can already return to House . In the chapter that inspired this post, House gives one twist to the phrase of Ockham, rethinking something like:

The simplest explanation is almost always someone goofed

This is also 100% applicable to our work every day in computer science. Often we are able to find network problems, problems of deployments, upgrades, etc.; When the 1, that we should do is talk to people to see or who has touched something. It is amazing how a little 5 minute session with people affected by a problem can help more than hours and hours of trial and error with a problem.

And to close, the Council always: fosters a culture of communication in your team, this is fundamental for the correct operation of the same.

Saludos @ Home

El Bruno