A new perspective

From time to time you get used to the environment you work with, you feel confident about what you do and you think that your approaches are kind of safe an standard.

That is something really naive for someone who is a developer, I have been/I am that person. During my first programming years I was exposed to Java and C++, these were the door-openers for my to the entire programming world.

I have set my expectations around the way these environments, and for a long time I thought that I was right in investing time and effort into making myself an expert on them. But then after a while, after some rough corners and rusted code I have thought to myself 'there must be a different way'.

And of course we have the Internet of things to ask for opinions, and that I did, and what a wonderful world I have found after that.

In my point of view, programming is much more like carpentry, there are tools to do the work, there are different kinds of wood, there are different kinds of furniture, and you can do many things with a different combinations.

As you might know carpenters have different styles and tools depending on how they learned to do their job, and I think of programming in a similar way, we do have really different ways to do things. And we should better know the most we can in order to make a decision.

So, to make it short, here are some programming languages that I would suggest you to learn (but learn, not just try, learn to the core by doing something with them):

• Ruby: You will get a whole new mindset about programming and problem solving, it combines metadata-based programming, imperative programming and functional programming.
• Go-lang: This is more than a language, is a whole environment that provides a practical and really simple programming experience.
• Clojure: Still learning this, but is so much different to what I normally use that I'm really having my brain twisted backwards.

The computer revolution hasn't happened yet

I'm a huge fan of conferences, I like documentaries and any kind of media that teaches something. And as a software developer I must say that there are lots of good resources for us to learn, to keep updated in technologies, concepts and general practices.

One of the best presentations I've seen so far is Alan Kay's keynote at OOPSLA 97, I don't know if there are any transcripts of it, but it is very valuable to listen what the man has to say, recommended.

Is not about the tool

Over and over I keep listening and reading in software development forums about certain types of questions:

• What is the best tool to do ?
• What is the perfect IDE for ?
• What can I use for modelling in ?

I know this because I started with those questions as well when I started a few years ago, but when dealing with different things during my short experience I have learned that the answers were never going to be enough, because the questions never were the correct ones in first place.

Let me explain that, the questions I (and some other developer folks) was asking during those initial years in my experience could be translated to other contexts in this way:

• What is the best hummer to build a chair?
• What is the best brand for office furniture?
• What pencil can I use to draw amazing designs?

If you can read them well, you can understand how lame they are. I should have focused first in the concepts that enable those tools to be useful. The tools are just the medium to build something, the major part of the problem is to identify and understand what to build first.

Of course is very useful (and mandatory) to know about the tools, but the effort should be directed to understand how thinks do and should work. That's the reason why the Business Analyst title is so hot at the moment, we as developers have sent the system's business to the background of things, that's my advice, focus on the concepts, business and things that have value, the tools will come eventually.    

Why I dislike the term 'Agile/Software/Practices Evangelist'

As software developers we often see these kind of adjectives on someone's profile, normally on LinkedIn or some resumes you get from time to time. I dislike this term, not because of the history behind it nor the intention it tries to give, but because of its meaning:

"the practice of relaying information about a particular set of beliefs to others with the object of conversion" - Wikipedia

The problem raises with the word 'beliefs', when working on systems and organizations, you shouldn't rely on beliefs, beliefs can or can't have proofs. You should rely in things that have a background or some basis that you can use in an argument.

If you are, let's say, an Agile Evangelist, you've already lost me. Because you described that you do what you do not because it is the best way you found of doing it, it is just because you believe it might be.

We, as people who work building reliable systems, should be careful about using something that doesn't have a valid argument beyond a belief, we should be able to say 'We chose this process because it has proven to be at least 50% more efficient'.

Argue about what you do, be critic of what you use, think and analyze, don't follow fashion, follow ideas with sustainable arguments.

Ant and Maven, a brief comparison

I've been working for the last three years and during this period of time the projects I've been involved with have the same discussion:

which build tool should I use?...and the most common answers were...Ant and Maven

You can check some statistics to see which one is going to rule the market, honestly I think Ant will never leave.

But I must say that there's a very important difference between Ant and Maven, Ant is task-oriented with the possibility of handling project-related configurations. And Maven is project-oriented with the possibility of handling task-related configurations.

Considering that, I have these questions that might help you to decide between the right tool:

Maven

1. Do you need to keep standard project structures?
2. Do you want to avoid manual tasks/steps?
3. Do your projects have dependencies to another projects/libraries/frameworks?
4. Do you have a fairly good Internet connection?
5. Do you like to follow the Convention over configuration way?

Ant

1. Do your projects are very different one from another?
2. Do your projects have very different structures?
3. Do you customize your projects so they behave in a very specific way?
4. Do you already have a tight workspace structure that doesn't fit in the Maven world?
5. Do you need to have full control over what your projects do?

Some of these questions might be incorrect, but those are the ones coming to my head right now, so feel free to use them or not.

Generic actions model

Have you ever tried to install something in a Linux distribution and have struggled with a dependency manager? such as DEB, RPM, PACMAN?

Dependency graph

I have a love/hate relationship with these models, sometimes they save my day, but some others are really, but really hard to deal with.

In software development you will find such scenarios, where you have something to do, and that thing will require another thing... and so on.

I mapped this model about a generic rule-dependency model:

• Action: Component doing some kind of work. All the dependencies are one-side oriente, and each dependency can have many other dependencies.
• ActionsRepository: A collection of sorted actions by any kind of criteria. Normally not allowing duplicated actions.
• ActionsExecutor: Component in charge of iterate and execute the actions.

TDD helps you find the way...when you are lost

There are times when you start a project, and you understand exactly what it has to do, you know the inputs, and the outputs. You might know even some of the inner logic in between, but you can't get your head around it.

That is, not to know how to do it. Not to know where to start from and where you are targeting to. This problem arises almost always you are dealing with something new, something you have never done before and perhaps have ever seen.

That's been the case for me in some projects I've worked on, some times it took me a while to get the right idea, after hours/days/weeks struggling with the logic and the results verification.

In my first days, I would do the verifications by hand, a tedious process where I would reply all the steps in order to verify that everything is working as expected. If something got broken, I would fix it and then start the tedious process again.

This was painful, and exhausting, that loop trapped me for months. I thought that someone else would have found a way to get this done without that much effort. Then I started reading about testing techniques, leading to best practices, disciplines....a hole world of professionalism and engineering is out there, you just have to seek it.

The concept that fit for my problems was TDD, it applied for the situations I experienced and its scope is what I was looking for, the cycle looks like this:

with automated tests and frameworks, and the most important....you know that you are done when you can't think on more tests to write!!!

I strongly suggest you to give it a try, it's a discipline that will make you a better, more responsible developer, and also will provide you a way of building targeted products in a safe way.

When you don't need a framework

I've been developing applications for a short time, from small to medium size codebases with many different features, requirements and environments. For all these applications I've always found the issue about the frameworks, sometimes this discussion takes days, or even weeks if the people involved is very passionate about Rails, Hibernate, JSF, CDI, and some others.

Mostly the discussions tend to be related to the benefits a framework can give us: speed, conventions, less coding, design improvements, being cool....

And for some projects the right frameworks have been a blessing, improving the developer experience and reducing development effort. But that's not always the case, because sometimes the frameworks can lead you to think that 'their' way to do it is the 'right' way.

'Their' way to do it can be 'right' for their intentions, but your application is not meant to be based on their intentions, but your customer ones. A framework should not define how your application is structured, how your business logic is wired, and not even how your tests are written.

I've always struggled with testing on a framework, because most of the times the requirements for its setup are so large, that makes you feel sick. And it's even worse if you are tied to certain technology because your customer has bought the 'sweetest' license in the market.

But well, here's my summary about frameworks:

Advantages

• Speed, not always, but a lot of frameworks are performance-oriented.
• Support, if it's open source, you will have a lot of it.
• DRY, yeah, you don't reinvent the wheel.
• Convention over configuration, very powerful, and saves lots of efforts.

Disadvantages

• With bad design decisions, you can marry your code with a framework, and that marriage is an ugly one
• Performance, as said, not all frameworks are performance-oriented.
• Test difficulty, you mean that I have to setup the entire framework stack in order to test a single operation?

When to use them

•  It's rare to find a reason not to use a framework, I would say that the question is not 'when to use a framework?', but 'how my application should be designed in order to be framework-agnostic?'.

When not to use them, or at least think twice before using them

• When its usage doesn't give you any advantages
• When you have a 'contractual' boundary with it
• When your team dislikes it
• When your tests take more than 10 seconds to setup its environment
• When the framework itself is untestable

Based on: Architecture, the lost years - Robert C. Martin

SE books you must read: Agile Principles, Patterns, and Practices in C#

As a disclaimer, I'm a Java developer, but this book can't be left aside. If you are a follower of the Clean Code movement this is the right book for you. Perhaps the most 'engineer-oriented' book written by Robert C. Martin and Micah Martin.

It covers several concepts about agile development, design patterns, programming, anti-patterns and some code katas to have fun with.

[ Agile Principles, Patterns, and Practices in C# ]

Plan de administración de proyectos: Farmacia

Ultimamente no he publicado nada en mi idioma nativo, pero creo que ahora voy a empezar una ensalada de posts incluyendo todos los idiomas de mi preferencia :-)

En este post comparto un documento elaborado para un curso de maestría en Ingeniería del Software, no es tal vez mi mejor trabajo ni tampoco estoy de acuerdo con muchos de los elementos usados:

• Diagramas de Gantt ( algun dia morirán, ojalá ).
• Diagramas de Euler (deben ser mutilados junto al anterior)
• Plan de aversión.
• Estimaciones sobre la completitud del proyecto (nunca se cumple).

No es mi intención decir que estos documentos son inútiles, pero en mi corta experiencia he tenido mejores resultados con Extreme Programming y las metodologías/frameworks de desarrollo ágil.

People it is worth following

Among software development there are a lot of resources, a lot of people worth of looking at it, but to find out who is good enough to follow may take some time. That's why's I'm summarizing the people I enjoy reading/listening to in any topic related to software engineering and development in general.

Robert C. Martin
The 'Master Craftsman', I've read some of his books and are pure gold, his experience and knowledge are outstanding, and you can still see him coding!

• Old blog http://butunclebob.com/ArticleS.UncleBob (it has some very interesting posts)
• New blog http://blog.objectmentor.com
• Clean coders http://www.cleancoders.com/, a bunch of great software development resources

Joel Spolsky
One of the heads behind StackOverflow, a hardcore developer that has been doing really cool things for more than a decade. His blog posts are extremely interesting and very, but very useful.

• Blog http://www.joelonsoftware.com/
• Hg init tutorial http://hginit.com/
• The Joel test 
• StackExchange http://www.stackexchange.com/ 

Jeff Atwood
Another of the heads behind StackOverflow, a very skillfull developer that has been delivering lots of tips, principles and advices for years.

• Coding horror http://www.codinghorror.com/blog/
• StackOverflow podcast http://blog.stackoverflow.com/category/podcasts/

Miguel de Icaza
He is the mind behind the initial Gnome project, started with Mono and now it's driving his own company called Xamarin. He might be controversial at times, but for sure it is worthy to follow him.

• Blog http://tirania.org/blog
• Xamarin http://xamarin.com/
• Mono http://www.mono-project.com/Main_Page

Scott Hanselman
One of the most productive developers I've seen, he's a .Net evangelist with years of expertise. His projects and blog are just amazing. Besides that he's a podcaster with various memorable recordings.

• Blog http://www.hanselman.com/blog/
• Hanselminutes http://www.thisdeveloperslife.com/
• This developer's life http://hanselminutes.com/

Software Architecture, lessons learned

There are very good developers, that can create great products out of nowhere without thinking too much. Well, I'm not one of those, it takes me a while to get the right idea, and several times I had to throw everything I've bee working on and start from scratch.

But even in situations like these, there are some things you learn from time to time.

Minimalism

This is something I learned from Robert Martin's Clean Code (but I think it just takes common sense). When your components are not meaningful and don't relate to each other in an almost 'natural' way, you need to refactor it. Your system might work beautifully, but your internal structure is a mess and it will create problems to future maintainers.

Keep it simple

Complex design leads to complex code, complex code leads to complex tests, and the mess has now started. The design has to be as simplest as possible, and your code has to be consequent to this. And by code I mean production code and the test units related, because that it's maintainable code too!. Check KISS Principle on Wikipedia.
 

Life time

System components and inner objects must follow the natural law, die. While shorter your objects live the better, are easier to handle, to test, and to refactor. Including memory usage improvements, as your objects are created and dropped as soon as they are used. This is something I find very useful, and I discovered by playing around with Google's Guice project.

Patterns

Check the patterns once a while, review your architecture, don't reinvent the wheel. There are several good references for it, but I tend to enjoy Martin Fowler's patterns (and the articles describing them). Have a look at the LMAX architecture.

Test Driven Development: Small tutorial

Some weeks ago I did a TDD presentation and for that matter I prepared a small tutorial of how to do it.
Details

1. I used Robert Martin's approach to TDD.
2. The example idea was taken from James Shore.
3. The QueryString(built in the tutorial) component is a simple HTTP parameters parser.

Http Parameters format: http://myhos.org/test?param1=value1&param2=value2

• HttpParser on github
• QueryStringTest.java