I have lots of fun here in Barcelona. It is a wonderful city. Always full of life, beauty and innovation. Last January, I had the opportunity to assist to what has become one of the the super-duper, most awaited events for the Agile Barcelona community: The Coding Dojo events hosted at the Runroom Headquarters. Now taking place almost every month! (Don't know what a Coding Dojo is? Take a look here)
It was interesting. It was fun, and between the drinks, the laughs, retrospectives, and the sound of people typing, the atmosphere of candidness and fellowship that surrounded us, was that of old friends getting together to chill out, talk and learn from each others. As a member of the community I think you would agree that it is great to have these events. They are free, or really cheap, and they help motivate, grow and enrich our community. I myself have learned a lot in them. I'm sure if you have been to one of them, you have too!
But, have you stopped to think what makes them possible?
People
Yes. That is the main factor. Not just the organizers, but also the people that show up! Us! The community! The sponsors and facilitators. This rich ecosystem "we" have created around learning and having fun while doing it. People, is the main reason I tweet at the community organized events. Why?
I tweet because, it helps create dynamism and break the inertia around the subject. It gets people to talk about it. It distributes, replicates and enriches the idea. Whatever it is! SCRUM, agile, javascript or anything else we feel like learning or doing.
It brings people into the community, and it brings them together through the conversation. The exchange of those ideas.
The same way you say thank you when someone offers you a hand, I think twitting is a way of doing something nice for the sponsors, lecturers and presenters of the events. It only takes a second to say thanks for the Gin & Tonics, or for lending us the place, or for giving this great talk. A second to show the people behind this things, that we really appreciate the gesture they are doing for us, so we can enjoy those amazing times.
The same way, I consider constructively saying what you liked or did not like from the event, is a way to contribute to make it better. Yes, constructively. If you just want to bitch, go sit in the bench with him. :)
In short. I believe tweeting can make the agile community stronger, richer and healthier. That is why I do it.
Do you?
Tuesday, February 14, 2012
Monday, February 13, 2012
Continuous Integration: Why the hell aren't you doing it already?
I had a very interesting talk with a developer friend of mine the other day. He was explaining to me how, the team he is working at is not using any kind of continuous integration software.
It was pretty much and eye opener, because, from what I heard, most of the problems that you would expect in that kind of scenario, where not happening! They release on time, and every two weeks. They do not loose changes, or have source conflicts adding new functionalities. Even when more than one developer is working on it. How did he manage to do that? Continuous Integration, he said. Although not the one you would normally expect to find.
It got me thinking. I asked myself, and now I ask you, this question: What is your definition of Continuous Integration?
If the answer was along the lines of "some software or script that builds your code when you check it into the source control system", I am afraid, you re missing the point. Continuous Integration or CI for short is not a particular kind software. Is not even a particular kind of tools or scripts. Its not about how you do it, but what you do. Its a practice. It is a process. It is, why not: a state of mind.
Yes, in my opinion you could say archiving "Nirvana" is not that different from getting your self and your team to interiorize, accept and incorporate continuous integration at an atomic level. No. I do not think I am over mystifying it. It is the equivalent of finding enlightenment and I will come back to this later.
But, the reason I am asking this question is not to explain, what it is or what he is doing. That has already been done several times and by people with more experience than I have. If you want to know go read the articles. Instead, I want to persuade you to give it a try if you have not. Maybe use it in your next pet project, or at work. I am hoping this post will give you the tools to make the sale to your team, or boss. Also, to help you optimize for developer happiness.
On the other hand, if you are already doing CI, hopefully this message will resonate with you at a personal level, and you will gain a greater understanding.
But, why would I want to use continuous integration in the first place? My process is dandy as it is right now, for me, and adding another layer of complexity and tools to it, doesn't seem to have a point.
Or does it?
What problems does Continuous Integration solve and How?
A co-worker and friend of mine brought to my attention this meme some time ago. I am pretty sure you have seen this situation before.
It is in Spanish, but the translation sort of would be:
John: None of the web validations work.
Girl: Well, it works for me locally!
Yeah... it is the unreasonable but yet frequent "It works on my machine" argument. Just because it works on your computer, does not mean it will work on the deployment environment, or the client's computer.
The problem here is that, usually, the developer's computer has certain particularities that allow the feature to function on his machine, but he forgets about them or does not know that they exist.
For instance, this could be changes done to his development database schema or data. For which he should have created migration scripts. New configuration files he added. Maybe, some sort of dependencies he needs but since he already had them beforehand, does not realize he should add them to the source control or packages manager. Maybe he was just careless and forgot to add that new source file to the version control.
All this means: "breaking" whatever is on the source control. Whatever is there, it is no longer deploy-able or demo-able, and if someone does a clean check out of the code, it simply, will not work. In some cases, it may take weeks or months before someone notices and tries to solve the problem. By then, it has probably grown out of proportion.
But the problem does not just end there.
When another co-worker tries to conciliate his changes with what is on the source control, it breaks his local copy of the code too! So he is going to go look and try to repair the mistake, and there you have it. More wasted time, delays, overlapping work effort.
Well.. guess what? If you are no alien to this kind of situations, you could benefit from CI.
Continuous Integration brings to the table isolation from each of the developer's environments by allowing a build to take place under a controlled environment. That is, an environment where the dependencies and configurations are known and theoretically, although not always possible, resemble the final production environment particularities.
This simple change in your software development process, allows you to know which dependencies you have and what you really need to do in order to build and deploy (in case you also stage your changes). So it reduces deployment risks and time, since you do it ever time you integrate (commit to the repository). If you wanted, you could give your testers or clients a deployment ready version on each commit and get some feedback.
As a by product of this you also make adding new developers to the project a lot easier. The time they spent configuring and tweaking what they get from the source control, to make it work, is ideally none. This is time saved that they can spend in really getting to know the ins and outs of the project, instead of "expending" it on putting up the environment.
Also, by executing and assessing this build on every commit, you can know right then and there, that something fishy is going on, because it will not build, run, or pass some tests. Did I forget that library? Did I forget to check in the new configurations, etc.
Not just that. If you are doing some kind of tests *grin*you are, right?*grin*, you can add them as part of the build process, so you can find out if you broke some of the functionality too. Also, if by any reason you have some code quality standard, you can also add that there!
Are you using some sort of continuous integration system and you do not have tests? That is like, ordering a diet coke, to wash down a big and greasy hamburger....
By the way, if you are not doing tests... Weigh the benefits and costs.... Well. Not really no. Just start doing them.... ;)
The truth is, tests that you can add to your build process increase your, and your team's confidence in the code state, at all levels. You make sure the code compiles. It passes all the tests for the new and old functionality (functionality is also correct) and it adheres to the conventions and quality checks that your company or your team has in place (structure, style, common errors, and metrics).
Just, pay particular attention at the fact that I am not talking about, unit tests, or integration tests, or anything in particular. Any kind of test will do, as long as you make it part of the build process. That includes, monkeys smashing their hands into the keyboard and mouse (or Q.A.). Although it does not have to be that way.You could have automated tests, but that is another story I am going to be talking about in later posts.
Last but not least, it helps you get rid of that code integration hell. Yes, that guy who is working on feature for two weeks and has never, ever, during that time, merged what is on the trunk into his branch or local copy. Yeah, the one that saves all the fun for the end. This is where the "continuous" comes into mind, and mostly why this post came to be.
When I mentioned adopting CI was a lot like reaching "Nirvana" this is what I was referring to. Tools are just that. A good hammer can be used to take a nail out, or put it in, although consequentially it can also be used to crack someone's skull open. It is all in the way we use them. This is where continuous comes in, because in a great deal it is referring to the human factor. To the when. It says: you need to integrate, and do it all the time!!! However, it is along with testing, the part that we neglect the most. We tend to forget about it, because it is difficult to tackle. Because it involves refactoring the wetware. It involves developers caring about this kinds of things, not just seeing the source repository as yet another kind of network folder.
You and your team need to commit, and therefore integrate, your changes, all the time. This prevents duplicated effort and provides an opportunity to have smaller and easier to handle conflicts as opposed to having one huge unsalvageable one! It saves you time, it saves you "bling bling", and it sure adds years to your lifespan. It also gives you an opportunity to resolve the conflicts as they happen, when the people who created them are there to solve them.
Just imagine one of your co-workers is working on a new feature or a bug. He has everything on his local computer and he says it is "finished". It works! But, he is leaving on vacations and he will not be here for your next release. You are in charge of putting everything together.
So now, you do what every sane person would do and try to commit the changes to the repository, only to find everything has conflicts. It turns out creating this new feature or solving this bug needed a lot of rework. What the hell are you going to do now?
You are going to "try" to solve the problem, and you may just do that, but you are definitively not the right man for the job. That, is what I mean. By the way, this is more common than you could think.
I hope I explained my point of view and maybe, sparkled in you that curiosity and ingenuity that takes to make things better for yourself and everyone else. Maybe now you can make an informed decision or pay better attention to the human factor in your CI system. Anyways I hope it was useful.
In upcoming posts I will be talking about how you can set up your own continuous integration server, for Java or .NET. Keep tuned, and happy coding!
It was pretty much and eye opener, because, from what I heard, most of the problems that you would expect in that kind of scenario, where not happening! They release on time, and every two weeks. They do not loose changes, or have source conflicts adding new functionalities. Even when more than one developer is working on it. How did he manage to do that? Continuous Integration, he said. Although not the one you would normally expect to find.
It got me thinking. I asked myself, and now I ask you, this question: What is your definition of Continuous Integration?
If the answer was along the lines of "some software or script that builds your code when you check it into the source control system", I am afraid, you re missing the point. Continuous Integration or CI for short is not a particular kind software. Is not even a particular kind of tools or scripts. Its not about how you do it, but what you do. Its a practice. It is a process. It is, why not: a state of mind.
Yes, in my opinion you could say archiving "Nirvana" is not that different from getting your self and your team to interiorize, accept and incorporate continuous integration at an atomic level. No. I do not think I am over mystifying it. It is the equivalent of finding enlightenment and I will come back to this later.
But, the reason I am asking this question is not to explain, what it is or what he is doing. That has already been done several times and by people with more experience than I have. If you want to know go read the articles. Instead, I want to persuade you to give it a try if you have not. Maybe use it in your next pet project, or at work. I am hoping this post will give you the tools to make the sale to your team, or boss. Also, to help you optimize for developer happiness.
On the other hand, if you are already doing CI, hopefully this message will resonate with you at a personal level, and you will gain a greater understanding.
But, why would I want to use continuous integration in the first place? My process is dandy as it is right now, for me, and adding another layer of complexity and tools to it, doesn't seem to have a point.
Or does it?
What problems does Continuous Integration solve and How?
A co-worker and friend of mine brought to my attention this meme some time ago. I am pretty sure you have seen this situation before.
It is in Spanish, but the translation sort of would be:
John: None of the web validations work.
Girl: Well, it works for me locally!
Yeah... it is the unreasonable but yet frequent "It works on my machine" argument. Just because it works on your computer, does not mean it will work on the deployment environment, or the client's computer.
The problem here is that, usually, the developer's computer has certain particularities that allow the feature to function on his machine, but he forgets about them or does not know that they exist.
For instance, this could be changes done to his development database schema or data. For which he should have created migration scripts. New configuration files he added. Maybe, some sort of dependencies he needs but since he already had them beforehand, does not realize he should add them to the source control or packages manager. Maybe he was just careless and forgot to add that new source file to the version control.
All this means: "breaking" whatever is on the source control. Whatever is there, it is no longer deploy-able or demo-able, and if someone does a clean check out of the code, it simply, will not work. In some cases, it may take weeks or months before someone notices and tries to solve the problem. By then, it has probably grown out of proportion.
But the problem does not just end there.
When another co-worker tries to conciliate his changes with what is on the source control, it breaks his local copy of the code too! So he is going to go look and try to repair the mistake, and there you have it. More wasted time, delays, overlapping work effort.
Well.. guess what? If you are no alien to this kind of situations, you could benefit from CI.
Continuous Integration brings to the table isolation from each of the developer's environments by allowing a build to take place under a controlled environment. That is, an environment where the dependencies and configurations are known and theoretically, although not always possible, resemble the final production environment particularities.
This simple change in your software development process, allows you to know which dependencies you have and what you really need to do in order to build and deploy (in case you also stage your changes). So it reduces deployment risks and time, since you do it ever time you integrate (commit to the repository). If you wanted, you could give your testers or clients a deployment ready version on each commit and get some feedback.
As a by product of this you also make adding new developers to the project a lot easier. The time they spent configuring and tweaking what they get from the source control, to make it work, is ideally none. This is time saved that they can spend in really getting to know the ins and outs of the project, instead of "expending" it on putting up the environment.
Also, by executing and assessing this build on every commit, you can know right then and there, that something fishy is going on, because it will not build, run, or pass some tests. Did I forget that library? Did I forget to check in the new configurations, etc.
Not just that. If you are doing some kind of tests *grin*you are, right?*grin*, you can add them as part of the build process, so you can find out if you broke some of the functionality too. Also, if by any reason you have some code quality standard, you can also add that there!
Are you using some sort of continuous integration system and you do not have tests? That is like, ordering a diet coke, to wash down a big and greasy hamburger....
By the way, if you are not doing tests... Weigh the benefits and costs.... Well. Not really no. Just start doing them.... ;)
The truth is, tests that you can add to your build process increase your, and your team's confidence in the code state, at all levels. You make sure the code compiles. It passes all the tests for the new and old functionality (functionality is also correct) and it adheres to the conventions and quality checks that your company or your team has in place (structure, style, common errors, and metrics).
Just, pay particular attention at the fact that I am not talking about, unit tests, or integration tests, or anything in particular. Any kind of test will do, as long as you make it part of the build process. That includes, monkeys smashing their hands into the keyboard and mouse (or Q.A.). Although it does not have to be that way.You could have automated tests, but that is another story I am going to be talking about in later posts.
Last but not least, it helps you get rid of that code integration hell. Yes, that guy who is working on feature for two weeks and has never, ever, during that time, merged what is on the trunk into his branch or local copy. Yeah, the one that saves all the fun for the end. This is where the "continuous" comes into mind, and mostly why this post came to be.
When I mentioned adopting CI was a lot like reaching "Nirvana" this is what I was referring to. Tools are just that. A good hammer can be used to take a nail out, or put it in, although consequentially it can also be used to crack someone's skull open. It is all in the way we use them. This is where continuous comes in, because in a great deal it is referring to the human factor. To the when. It says: you need to integrate, and do it all the time!!! However, it is along with testing, the part that we neglect the most. We tend to forget about it, because it is difficult to tackle. Because it involves refactoring the wetware. It involves developers caring about this kinds of things, not just seeing the source repository as yet another kind of network folder.
You and your team need to commit, and therefore integrate, your changes, all the time. This prevents duplicated effort and provides an opportunity to have smaller and easier to handle conflicts as opposed to having one huge unsalvageable one! It saves you time, it saves you "bling bling", and it sure adds years to your lifespan. It also gives you an opportunity to resolve the conflicts as they happen, when the people who created them are there to solve them.
Just imagine one of your co-workers is working on a new feature or a bug. He has everything on his local computer and he says it is "finished". It works! But, he is leaving on vacations and he will not be here for your next release. You are in charge of putting everything together.
So now, you do what every sane person would do and try to commit the changes to the repository, only to find everything has conflicts. It turns out creating this new feature or solving this bug needed a lot of rework. What the hell are you going to do now?
You are going to "try" to solve the problem, and you may just do that, but you are definitively not the right man for the job. That, is what I mean. By the way, this is more common than you could think.
I hope I explained my point of view and maybe, sparkled in you that curiosity and ingenuity that takes to make things better for yourself and everyone else. Maybe now you can make an informed decision or pay better attention to the human factor in your CI system. Anyways I hope it was useful.
In upcoming posts I will be talking about how you can set up your own continuous integration server, for Java or .NET. Keep tuned, and happy coding!
Thursday, February 9, 2012
Video Compilations - Agile Practices
Ever since I heard of agile I have been interested in it, not just because of the school of thought behind it but also because being the lazy programmer that I am, anything that helps me and the team out to be more productive is always welcome.
Last night I was going through some posts on G+ and I came across a video of a presentation by Jon Skeet on Skills Matter and along side there were a couple of other presentations on the subject of agile. So, as it often happens when I am in the learning mood I could not just stop there and I had to watch them all. Which gave me the idea of starting a series of posts where I would link to conferences, presentations, etc. on different subjects.
So here is the first of these posts. This time the subject is Agile Development Practices and it touches as much as the theoretical side as the practical side. Take a look and let me know if you find them useful.
Without further delay, here is the list and until next time!
1. Shock therapy as a strategy for booting up teams.
2. The Cosmic Stopping Problem, otherwise known as the choice uncertainty principle.
3. Punctuated equilibrium - how software systems evolve
Take advantage of these concepts and you may find a way to achieve the ultimate potential of a team. This session will be a "Deep Agile" presentation keying off topics presented to engineers at MIT.
However, with the rising popularity of agile, mainly due to lack of experience or management over-expecting results,in coming years many agile projects will fail miserably. Agile is not the silver bullet. In his enthusiastic style, speaker Sander Hoogendoorn, global agile thought leader at Capgemini and involved in agile projects since the mid-nineties, demonstrates the differences in traditional and agile projects, and shows why agile projects will fail – independent of the process used.
Sander elaborates on a series of agile anti-patterns that people will recognize immediately. Think of the Scrumdamentalist, Agile-In-Name-Only, the Pseudo-Iteration, Guesstimation, the Bob-the-Builder Syndrome, Parkinson’s Law, the Agile Project Manager and Student Syndrome – of course, with many embarrassing examples and anecdotes from real-life projects.
Last night I was going through some posts on G+ and I came across a video of a presentation by Jon Skeet on Skills Matter and along side there were a couple of other presentations on the subject of agile. So, as it often happens when I am in the learning mood I could not just stop there and I had to watch them all. Which gave me the idea of starting a series of posts where I would link to conferences, presentations, etc. on different subjects.
So here is the first of these posts. This time the subject is Agile Development Practices and it touches as much as the theoretical side as the practical side. Take a look and let me know if you find them useful.
Without further delay, here is the list and until next time!
The Agile Buffet
Scrum,Feature Driven Development,extreme programming, DSDM, Test Driven Development, Business Driven Development, Kanban - wow,lots to choose from. Why choose one when you can take the best from all of them? Let's talk about how to identify the best aspects of different methodologies and how you can work with them.
Kanban and Scrum - making the most of both
There's a lot of buzz on Kanban right now in the agile software development community. Since Scrum has become quite mainstream now, a common question is "so what is Kanban, and how does it compare to Scrum?" Let's clear up the fog. What are these things? Where do they complement each other? Are there any potential conflicts? The purpose of this session is to clarify Kanban and Scrum by comparing them, so you can figure out how these may come to use in your environment.Visual Management for Agile teams
Join Visual Management blog author Xavier Quesada Allue as he explains basic patterns and introduces dozens of original ideas for building great task boards and visually managing your work and that of your teams.Self-Organization: The Secret Sauce for Improving your Scrum team
High performance depends on the self-organizing capability of teams. Understanding how this works and how to avoid destroying self-organization is a challenge. Until you understand complex adaptive systems and how Toyota works it is difficult to improve team velocity. Jeff will discuss three core topics:1. Shock therapy as a strategy for booting up teams.
2. The Cosmic Stopping Problem, otherwise known as the choice uncertainty principle.
3. Punctuated equilibrium - how software systems evolve
Take advantage of these concepts and you may find a way to achieve the ultimate potential of a team. This session will be a "Deep Agile" presentation keying off topics presented to engineers at MIT.
Distributed Agile Development
Most agile methodologies tend to assume that the team is co-located in a single team room. They give little guidance as to how to address team distribution although proven practices are starting to emerge within the community. The Microsoft patterns & practices team has been experimenting with distributed teams for several years, mining proven practices from the community and experimenting them out on numerous agile projects. This talk summarizes those learning and proven practices and gives examples of their application – both good and bad – within their teams.Scrum Tuning: Lessons learned from Scrum implementation...
Adwords introduced a Scrum implementation at Google in small steps with remarkable success. As presented at the Agile 2006 conference this exemplifies a great way to start up Scrum teams. The inventor and Co-Creator of Scrum will use this approach in building the Google Scrum implementation to describe some of the subtle aspects of Scrum along with suggested next steps that can help in distributing and scaling Scrum in a "Googly way".Continuous Integration and Continuous Deployment
As software developers, we face a risky, time-consuming and painful process in delivering software. The solution the delivery of software continuously through build, test and deployment automation. This session will talk about how we can move from CI to continuous delivery. It will also help to distinguish between CI and continuous deployment.Emergent Architecture
Agile software development emphasizes that some increment of business value be delivered every iteration. How can this happen when your iterations are two weeks in length and you estimate it will take you two months just to design the database and the access layers? The answer is to think in differently.Agile Anti-Patterns!
The popularity of agile software development processes and methodologies is imminent and fast growing. Many organizations and projects turn towards agile to help solve the problems of traditional software development. Scrum,extreme programming,test driven development,and lean are no longer the new kids on the block.However, with the rising popularity of agile, mainly due to lack of experience or management over-expecting results,in coming years many agile projects will fail miserably. Agile is not the silver bullet. In his enthusiastic style, speaker Sander Hoogendoorn, global agile thought leader at Capgemini and involved in agile projects since the mid-nineties, demonstrates the differences in traditional and agile projects, and shows why agile projects will fail – independent of the process used.
Sander elaborates on a series of agile anti-patterns that people will recognize immediately. Think of the Scrumdamentalist, Agile-In-Name-Only, the Pseudo-Iteration, Guesstimation, the Bob-the-Builder Syndrome, Parkinson’s Law, the Agile Project Manager and Student Syndrome – of course, with many embarrassing examples and anecdotes from real-life projects.
Google Tech Talks by Misko Hevery about Testing and Refactorization
This is set of talks given by Misko Hevery at Google Tech Talks. It is definitely worth watching since it touches on the key principles of why we write code that we can't test and how to avoid or re-factor this mistakes out.Wednesday, February 8, 2012
Code Kata - Hidden Global States
I'm sure that most of you already know what a code kata is. For those who don't, you should already be googling about it.
I may not have mentioned this before, but we have started a set of sessions, seminars, talks, etc. at the company where I currently work at, aimed to improve our skills as programmers and the quality of our code base and products.
Everything is going well but as the 3rd conference on TDD and design principles was approaching, we started having the feeling that we need to get a little more technical about what we had discussed on previous sessions. You know what they say its easy to talk the talk.. but can you walk the walk...?
So, I decided to propose the idea of hosting this Code Katas every other week, so that we could touch more on the practical side of things. Which brings me to the subject of these post.
During some of the sessions, most of the examples where kind of textbook-like. Meaning that they got the point through, and where small and simple enough so that everyone could follow and understand them. However, most of the examples although illustrative were not real life situations, and we know how different real life can be...
So as I was looking for exercises that would allow us to practice on the subjects of the previous sessions which were about SOLID programming design principles and writing testable code, I did what anyone in my position would do, and started by googling for a few Katas that would suit my purpose.
However I was shocked at the lack of Katas touching refactorization of smelly production code. So, after a few unsuccessful attempts I decided to turn to the matrix of all problems and digging through some of the code base, I found some samples that where simple enough to use as Katas. I'm sure there are many more hidden smelly gems in there, and I will continue to post them in this blog as I find them. This is just the first of them.
The Kata
Suppose the following code is production code that has no tests. You must clean up the code as much as you can while at the same time ensuring that you don't break any of the functionality that is already depending on it. On the process ensure you end up with unit tests for the class that you are refactoring.
The Objective
The objective of this kata is to practice decoupling of global states (singletons) and design for testability using advanced object oriented design principles.
The Code
NumGenerator.java
package org.something.service;
public interface NumGenerator {
public String generaNumSessio();
public String generaReferenciaNotificacio();
public String generaIdSolicitud();
}
NumGeneratorImpl.java
package org.something.service;
import java.util.Calendar;
import org.springframework.stereotype.Service;
import org.something.service.NumGenerator;
import org.something.util.constants.NotificacionsConstants;
@Service
public class NumGeneratorImpl implements NumGenerator {
public String generaNumSessio() {
Calendar cal = Calendar.getInstance();
return "SES"+cal.get(Calendar.MINUTE)+cal.get(Calendar.SECOND)+"/"+cal.get(Calendar.DAY_OF_MONTH)+cal.get(Calendar.MONTH)+cal.get(Calendar.YEAR);
}
public String generaReferenciaNotificacio() {
Calendar cal = Calendar.getInstance();
return "REF/NOTIFICACIO_"+cal.get(Calendar.MINUTE)+cal.get(Calendar.SECOND)+"/"+cal.get(Calendar.DAY_OF_MONTH)+cal.get(Calendar.MONTH)+cal.get(Calendar.YEAR);
}
public String generaIdSolicitud() {
Calendar cal = Calendar.getInstance();
return NotificacionsConstants.CAOC+cal.get(Calendar.MINUTE)+cal.get(Calendar.SECOND)+cal.get(Calendar.MILLISECOND)+"/"+cal.get(Calendar.DAY_OF_MONTH)+cal.get(Calendar.MONTH)+cal.get(Calendar.YEAR);
}
}
Happy coding! Let me know if this was helpful to you!
Where does bad code come from?
Let me tell you a story. There is this developer. Who could be you or me, or any other of the thousands out there. He goes to work every day, not because he has to, but because he wants to, because he loves what he does. But, no matter what, there is always something that prevents him from enjoying his day fully: bad code.
Yes, that putrid, stinking amorphous "thing", that after a while if you are anything like me, makes you want to cry. The subject of probably more than one song and definitely, the cause of a great deal of the headaches developers suffer.
But... you have to wonder how is that bad code comes to be? Where does it come from? How is it that even if code is not organic, if its not a piece of meat, it starts degrading and rotting like one.
I know, I known... someone else wrote it. The bad code I mean. ;) But... What is that the other guy does, or doesn't do to make it rot?
I think the answer is simple. Writing software, and particularly software design is about how you structure your software. What goes where, who talks to who, which parts of your code do you allow to do what, etc. That is pretty hard to do properly most of the time. There is of course, a lot more into it. I am for the brevity of this post over simplifying it. But I personally think that is one of the main concepts behind it. It is also, the main reason for bad code to exist: dependency management. Or to say it properly: bad dependency management. You don't see it? Keep reading.
So... What goes wrong with software development?
Let's go back to our developer friend. Let's say he starts a new project, and that he has all his requirements ready! What does he do?
He goes and draws these big diagrams. Because who doesn't like drawing? Right?. He creates this huge representation of what he is going to do, maybe database schema, gantt chart, etc. When he is finished, and after a few minutes of contemplating his magnificent work of art, showing it to everyone, etc. he finally sets of to write the code.
The code then flows like a river. It just does! Lines and lines of code come out until its finished! Then he ships it and that's it! He lives happily ever after!
Ok. In the words of Orson Welles: If you want a happy ending, that depends, of course, on where you stop your story.
Yes, sadly, we know that's not the whole story. Because, after shipping ,what actually happens is that people start using this code. Not only that. They start requesting changes. What? Then some more changes. Then even more changes, and after that.. You guessed it right!... more changes! Finally, the poor guy who is developing it just decides to end it all and kills himself.
Why did this happen?
Well, this developer didn't manage his dependencies so the code started to putrefy. It became rigid. It became ugly, hard to maintain, hard to modify, hard to fix and easy to break. It probably was not even easy to test. It started rotting, to have a mind of its own and at one point the stench was so bad he had no other choice but to run away from it. Creator running away from its creation like a Frankenstein.
Its not the changes that created the problem, but the way he dealt with them. I mean, who has not written one of those famous patches, just to annotate it with a big TODO, o FIXME. Always with the hope that, some day, when you have a time, you will come back later and do some house keeping. We know that day, is yet to come.
This concept is not new. Not at all! In fact, I am positive most developers and projects that I know of, suffer from some kind of technical debt. You don't (or at least I don't) write perfect code from the start most of the time. Its a process! An evolution. It is a part of the software development processes to create that technical debt, and to repay it. When, and how you decide to do it, is what makes the difference.
Will you pay it at the end, with all its interest and let it ether drive the project to the ground, or in many cases, constraint development and probably dictate the architecture. Or will you chose to repay it as you go, and keep your architecture evolving and open to as many possibilities as you can. In any case, if you are not good on regularly doing your house keeping, at least, you can train your nose to detect early that something needs two minutes of your time.
Which brings me to my next point.
How do you know your code is starting to decay?
Answer: When you feel the smell.
Doing some research, I found that the main code smells have been already classified by Robert C. Martin. If you don't know who "Uncle Bob" is, and what he has done, you go Google it! Now! Well.. not now, first finish reading my post... but I mean it. ;)
These groups in which he classified code smells are:
Rigidity
If your code starts getting stiff, like a dead body, it may as well be. That means, if you can't take care of that little thread that is showing up out of place, without unweaving the whole t-shirt, you have a problem. By that I mean, if you have a bug that in order to fix it you have to go around the whole code base touching stuff, your code is definitely rigid.
Fragility:
Have you ever had a system that got broken by the most unexpected and unrelated thing ever. Kind of, the butterfly effect. A butterfly flaps its wings half a world away and a tsunami ends up destroying your house.
For example, miss-spelled magic strings. The typical case of the new guy that sees one of those magic strings and can't resist the temptation to correct the spelling mistake. But it turns out that mistake is hard coded on views and probably even 3rd party systems, and after a while you find out half the application stopped working. Yeah... I've been there...
Mobility:
How much of your code can you reuse? If you wanted to rebuild your code using a different MVC framework, or maybe move it into a desktop application. How much of it would you have to write again? If your answer is, almost all of it, you have a mobility (re-usability) problem. In fact you probably have an architectural problem, but that is another story.
Viscosity:
We developers, are lazy. That's a fact. When something is tedious and boring to do, but we "have" to do it, chances are that we will try to find ways not to. This particular code smell type, comes in two flavors.
What I mean is, when faced with two options, one that solves the problem and maintains the architecture, and one that does not, if the proper solution is much harder to implement, developers will not tend to use it. There you go, sticky everywhere, the view accessing the database, or the model that knows about the services. Uncle Bob call's this kind of viscosity: by design.
On the same line if there are several ways of making a change but the one that is not a hack, includes a 2 hours build. People will use the hacks. They will try to find ways in which to avoid that 2 hours build, and you would be surprised how inventive some people can be. In this particular case where the development environment is the one conspiring against you, you have an environmental viscosity problem.
I think we can agree that a 2 hours build and people committing changes where they compromise the architecture are problems on their own. The important part here is to notice how subtle things directly affect the way you manage your dependencies, which in turn, if not addressed properly, can, and will deteriorate the quality of the code base.
Anyways... In subsequent posts I am going to be talking a lot more on this subject and how can you actually hone your skills at managing your dependencies so that this code smells eventually get reduced to a minimum. I will also be talking about SOLID Software Design Principles and lots of other stuff like re factorization of legacy code and unit testing.
Keep tuned!
Yes, that putrid, stinking amorphous "thing", that after a while if you are anything like me, makes you want to cry. The subject of probably more than one song and definitely, the cause of a great deal of the headaches developers suffer.
But... you have to wonder how is that bad code comes to be? Where does it come from? How is it that even if code is not organic, if its not a piece of meat, it starts degrading and rotting like one.
I know, I known... someone else wrote it. The bad code I mean. ;) But... What is that the other guy does, or doesn't do to make it rot?
I think the answer is simple. Writing software, and particularly software design is about how you structure your software. What goes where, who talks to who, which parts of your code do you allow to do what, etc. That is pretty hard to do properly most of the time. There is of course, a lot more into it. I am for the brevity of this post over simplifying it. But I personally think that is one of the main concepts behind it. It is also, the main reason for bad code to exist: dependency management. Or to say it properly: bad dependency management. You don't see it? Keep reading.
So... What goes wrong with software development?
Let's go back to our developer friend. Let's say he starts a new project, and that he has all his requirements ready! What does he do?
He goes and draws these big diagrams. Because who doesn't like drawing? Right?. He creates this huge representation of what he is going to do, maybe database schema, gantt chart, etc. When he is finished, and after a few minutes of contemplating his magnificent work of art, showing it to everyone, etc. he finally sets of to write the code.
The code then flows like a river. It just does! Lines and lines of code come out until its finished! Then he ships it and that's it! He lives happily ever after!
Ok. In the words of Orson Welles: If you want a happy ending, that depends, of course, on where you stop your story.
Yes, sadly, we know that's not the whole story. Because, after shipping ,what actually happens is that people start using this code. Not only that. They start requesting changes. What? Then some more changes. Then even more changes, and after that.. You guessed it right!... more changes! Finally, the poor guy who is developing it just decides to end it all and kills himself.
Why did this happen?
Well, this developer didn't manage his dependencies so the code started to putrefy. It became rigid. It became ugly, hard to maintain, hard to modify, hard to fix and easy to break. It probably was not even easy to test. It started rotting, to have a mind of its own and at one point the stench was so bad he had no other choice but to run away from it. Creator running away from its creation like a Frankenstein.
Its not the changes that created the problem, but the way he dealt with them. I mean, who has not written one of those famous patches, just to annotate it with a big TODO, o FIXME. Always with the hope that, some day, when you have a time, you will come back later and do some house keeping. We know that day, is yet to come.
This concept is not new. Not at all! In fact, I am positive most developers and projects that I know of, suffer from some kind of technical debt. You don't (or at least I don't) write perfect code from the start most of the time. Its a process! An evolution. It is a part of the software development processes to create that technical debt, and to repay it. When, and how you decide to do it, is what makes the difference.
Will you pay it at the end, with all its interest and let it ether drive the project to the ground, or in many cases, constraint development and probably dictate the architecture. Or will you chose to repay it as you go, and keep your architecture evolving and open to as many possibilities as you can. In any case, if you are not good on regularly doing your house keeping, at least, you can train your nose to detect early that something needs two minutes of your time.
Which brings me to my next point.
How do you know your code is starting to decay?
Answer: When you feel the smell.
Doing some research, I found that the main code smells have been already classified by Robert C. Martin. If you don't know who "Uncle Bob" is, and what he has done, you go Google it! Now! Well.. not now, first finish reading my post... but I mean it. ;)
These groups in which he classified code smells are:
Rigidity
If your code starts getting stiff, like a dead body, it may as well be. That means, if you can't take care of that little thread that is showing up out of place, without unweaving the whole t-shirt, you have a problem. By that I mean, if you have a bug that in order to fix it you have to go around the whole code base touching stuff, your code is definitely rigid.
Fragility:
Have you ever had a system that got broken by the most unexpected and unrelated thing ever. Kind of, the butterfly effect. A butterfly flaps its wings half a world away and a tsunami ends up destroying your house.
For example, miss-spelled magic strings. The typical case of the new guy that sees one of those magic strings and can't resist the temptation to correct the spelling mistake. But it turns out that mistake is hard coded on views and probably even 3rd party systems, and after a while you find out half the application stopped working. Yeah... I've been there...
Mobility:
How much of your code can you reuse? If you wanted to rebuild your code using a different MVC framework, or maybe move it into a desktop application. How much of it would you have to write again? If your answer is, almost all of it, you have a mobility (re-usability) problem. In fact you probably have an architectural problem, but that is another story.
Viscosity:
We developers, are lazy. That's a fact. When something is tedious and boring to do, but we "have" to do it, chances are that we will try to find ways not to. This particular code smell type, comes in two flavors.
What I mean is, when faced with two options, one that solves the problem and maintains the architecture, and one that does not, if the proper solution is much harder to implement, developers will not tend to use it. There you go, sticky everywhere, the view accessing the database, or the model that knows about the services. Uncle Bob call's this kind of viscosity: by design.
On the same line if there are several ways of making a change but the one that is not a hack, includes a 2 hours build. People will use the hacks. They will try to find ways in which to avoid that 2 hours build, and you would be surprised how inventive some people can be. In this particular case where the development environment is the one conspiring against you, you have an environmental viscosity problem.
I think we can agree that a 2 hours build and people committing changes where they compromise the architecture are problems on their own. The important part here is to notice how subtle things directly affect the way you manage your dependencies, which in turn, if not addressed properly, can, and will deteriorate the quality of the code base.
Anyways... In subsequent posts I am going to be talking a lot more on this subject and how can you actually hone your skills at managing your dependencies so that this code smells eventually get reduced to a minimum. I will also be talking about SOLID Software Design Principles and lots of other stuff like re factorization of legacy code and unit testing.
Keep tuned!
Subscribe to:
Posts (Atom)