Showing posts with label programming. Show all posts
Showing posts with label programming. Show all posts

Tuesday, August 13, 2013

being "agile" does not means being "scatterbrained"

I am not (and I do not attempt to be) a Scrum Master or any kind of agile guru, for that I have friends like Jesús Enrique Méndez (http://agileinpills.wordpress.com and his initiative http://www.agileopenspace.org), Gustavo Bonalde (http://gbonalde.blogspot.com/) or Carlos Gabriel (https://twitter.com/CarlosGabriel_). Anyway I am a guy that has spent a lot of time researching, studying, watching in silence how people do the stuff and secretly making some experiments; so I have developed my own opinions.

First, I believe that we need to be really agiles in our process, any kind of waste should be minimized, so why should we keep doing things in the most costly way (time related)?

Second, we need to be productive, that means that expending a year to develop a new functionality is unacceptable, even if you are developing an Operating System the process should not be that long.

Third, your business model or your economical maturity level could give you an advantage over other companies but that does not mean that you are allowed to make mistakes and if you are a small company or startup you will need to use properly any piece of resource that you can get.

Thinking in those three ideas, I usually see how people start being "agile" by ignoring any kind of design or worst, they start being "agile" and they stop thinking in the problem or the possible solutions and they start doing "anything" to solve the problem. I do not want to talk about efficiency or any related aspect to that, but let's take a time to understand the situation, let's draw something, let's get to the reasons of our problem and then we can solve it looking an good/optimal solution. If you want to be "agile" you can start by using the best simple solution instead of the most complicated solution. At this point my two advices are:

remember that thinking and designing are not sins.

keep it simple, do not oversize the problem.


I also see how people try to reduce the development cycle by doing something and sending it to the production environment as soon as they finish, then everybody gets crazy because something is falling; well, when I was a young developer, I learned about a technique (almost magical) to minimize troubles, it is called TESTING, we can not be in a rush and forget about tests, we HAVE to test our codes, obviously something can change and something could fail, but that HAS to be the exception and not the rule. I have saw people that is unable to send a functionality to production without having tons of errors and then breaking everything. Today, we have tools to automate our test, we can use jenkins or any other but we have to use it.

clumsy is not agile.

lazy is not agile.

testing is important for everybody, and we know that things can fail but it should be the exceptions.  

you can be agile testing, that does not mean NO TESTING.

Finally, I have saw people that as soon as they start getting error they start blaming any single API, third party tools or even the astrological configuration of mercury. People, let's face it, usually when something goes wrong we are the responsible, if we work in an orderly way, if we document our code, splitting the problems in smaller problems could make us agiles replacing broken pieces, fixing bugs or improving functionalities.

Well my friends, if you are trying to become an agile developer then you have my bless, just do it, but do it in the right way, do not become a "scatterbrained" trying to speed up developments.


Monday, July 1, 2013

may the IDE be with you

last week, following the recommendation of +Pablo and +Omar, I decided to give a chance to PyCharm. Well my friends, it is a charm! the IDE really does the work. When I am refering to "the work", I am talking about support, speed in the development, contextualization and HELP!! It has good PEP8 formatting, code analysis, code assistance, refactoring and more.

we develop IDEs because we have the need to increase our productivity as much as possible; some of us feels comfortable using a simple text editor, well.. not so simple if you (like me) are using Sublime Text, you have to see the demos and all the configuration options like the available in Alex Maccaw's Blog in order to fall in love with this editor.

anyway, the important part of history is this:

IDEs are made by developer for developer, that try to put their needs in automated tools, those needs that many of the times collide with ours. So, try some IDEs, pick whatever helps you to be more productive, remember that for us IDEs are productivity tools. And  do not forget:


may IDE be with you




Friday, June 28, 2013

learning new languages and tools, alone but with help.

I know that many of us are used to learn how to write code in any new language in the hard way, that means doing examples from some web page or reading a book, then we run our code and if something is not working properly, we can use some of our helping options, like 50/50, call a friend or ask the audience.. anyway we will end using google.

What if i tell you that it is possible to get help interactively while doing examples, with explanations about what are you doing, and hints in case you are lost as Lindbergh's son? Yes. it is possible, I just started using codeacademy for learning Ruby in the right way.

But, the thing I like most is that you can teach also, so it is possible to help others to get that knowledge that you hold for any specific language, API, etc.

My invitation is to try this, maybe learn python or ruby, and if you enjoy it learn more and more, but if you have some extra time, please give it back and build some interesting course.

Enjoy the learning.