code.between.lines

So, here is the thing:  is pretty common to hear people saying they write good software and apply software methodologies and techniques, and it is also pretty common, though, that those same people don’t actually build good, maintainable, software.

The biggest reason for that is probably because people are usually all about the buzz but not about pursuing quality and continuously improving their own skills. They are so worried about strictly following what someone, who they look up to, said than actually looking into their own work and understanding how they could improve it. Everybody does that at some point. I used to.

Software craftsmanship is all about realizing each code is unique and learn to apply certain patterns on it while still respecting the uniqueness of it. If the person you look up to made a certain design decision, doesn’t necessarily mean you should take the same decision in your project but rather understand why the decision was made and apply that knowledge.

Another reason is definitely the misunderstanding  of certain methodologies practices, techniques, and values. Understanding the agile values is definitely the most important thing you should do, if you really care about being agile. All agile methodologies, practices and techniques are based on those values and, again, you shouldn’t follow those strictly but rather try to understand what are the benefits of each of them and when and how to apply them.

For example, it is pretty easy to do test-driven-development but you will definitely not get the whole benefits if you don’t understand why you are doing it. There are reasons why you should write tests first and not after: writing your tests first make you think about how the application or unit under test should behave and how it should interact with it’s collaborators. So, in the end of the day, it is more of a software design issue than actually testing.

Other practice I usually see being wrongly applied is the “Do the simplest thing that could possibly work” concept. Following this doesn’t mean you should do the most raw implementation, overseeing everything you know about good software. It means not trying to foresee future features and add extra complexity on your application if it is not necessary, at least yet.

Unfortunately, some people think that structuring your code properly, following good OOP practices and making sure your code will be easier to maintain and extend in the future, is the same of adding extra complexity. I mean, you definitely don’t want to add things that are not necessary but you should still make an effort to make your code better, even if that means having more classes or more lines of code.

If you look at the Extreme Programming developing cycle, it defines it as Write Test -> Write Code -> Refactor. If you think about it for a second, the values of each step are:

  1. Write Test: analyze and determine the best design for your code while writing regression tests. (Working software over comprehensive documentation, Continuous attention to technical excellence and good design enhances agility.)
  2. Write Code: implement the current feature, making the tests pass, and nothing else. (Do the simplest thing that could possibly work)
  3. Refactor: improve the current implementation so that it follows good OOP practices and it is easier to maintain. (Responding to change over following a plan, Continuous attention to technical excellence and good design enhances agility.)

I often see people skipping the Refactor step and if you pay attention to the values, it is as important as the others. If you are skipping any of these steps or doing them without paying attention to the actual values, you’re doing it wrong. And that is also true for all the other existing practices from different methodologies out there.

So, wake up, start pursuing quality and stop blindly following practices.

Categories

Twitter Updates

Latest bookmarks

Archives