Expert thoughts from our software developers and design leaders.
As some of you may know, our team has been working with Go for some time and we have always been using CircleCI to run our test suites, we would like to share our circle.yml file, it would help for your Go projects.
Since I joined to the company and during the implementation of projects in which I participated, I have conducted a serie of activities for the management of those projects, activities and daily meetings, monthly, retrospectives among others, all this because in our company uses Scrum as a framework for managing our projects. Deepening about Scrum, it woke up in my desire to learn and perform the activities of a ScrumMaster.
Sponsored by our company on March 2 of this year I traveled to Bogota along with two co-workers, Bryan and Jessica, for the ScrumMaster certification course, the course lasted two great days, and while is true that we get to the course with a lot of practical knowledge about the Scrum/Agile world, Kleer (the company who conducted the course) used every possible tool to establish these concepts and secure them in a dynamic and practice way.
That was the most exciting part of the course, and where I was putting my expectations, because during flight to the CSM many times I wondered if it was possible, I mean, to prepare a group of people to perform activities of a ScrumMaster in two days. It was great to notice how with the passing of activities we were gradually increasing most knowledges about Scrum and the role of ScrumMaster and that was gaining sense why those meetings and activities that as company member we have done in each of our projects.
After completing the course Bryan, Jessica and I have been sharing our fresh ideas and experience with our team through presentations, that in order to put in practice what we have learned and also we wanted to get feedback from our own knowledge, at the end we answered some doubts that any of them could probably have.
Our goal as ScrumMaster when resolving these doubts beside finishing with them, it was to improve the self-management of members team that finally ends up guaranteeing better quality and value for our clients as well as the growth of ourselves as a professionals.
Ultimately my participation in the CSM was a great experience, I had the opportunity to interact with people from different professions and countries and provide feedback of knowledge, I met places of the city of Bogota where the course was held during free time and achieve one of the course objectives that it was get the ScrumMaster certification.
Common company organizations figures closed management groups, where the tasks related to maintain and guide companies processes rely on a hand of experienced people, while in some cases this could ‘work’ if we measure this based on short term financial results, this is not a good start to make a happy environment inside the company and in the long term this will lead to very bad results, after all, what is a company without his people ?.
Let me share something interesting:
If a system is to be stable the number of states of its control mechanism must be greater than or equal to the number of states in the system being controlled. – The Law of Requisite Variety (W. Ross Ashby)
Based on this we could initially deduct 2 things.
The first one is that in order to control/direct a team of people, you need a human being, another kind of being wont be able to do it, that because after all, who could understand a human being with all his complexity more than another human?.
Yes, I know what you’re thinking, sometimes even we humans don’t understand other human behaviour, and everyone who has been on management for a while can say it, there are some situations that we could say for sure a computer would not be able to manage because after all are very hard for humans, so hard that sometimes some of us end up believing that these were resolved spontaneously.
But this take us to the second deduction, that is, that 1 human wont ever be as complex as 2, or 3, or N, that because the number of states in the system being controlled will always be greater than the number of states in the controller, or said in other words: 2 persons will always be more complex than one.
So, how to control a development team ? what’s the best strategy to control a team successfully?
Well, it may sound crazy, but 2 persons will always be as complex as 2 persons, if all the team-mates are involved in the management tasks then the system will be stable, that means team will be able to manage itself, and at the end of the journey there will not only be one big smile on the manager, but rather an entire team happy for the results.
After all delegating is the best way of making the team part of the company and not another piece being used only to produce good financial results. Every team member would not be prepared to do every single the team tasks but, is our task as managers to max their qualities in favour of the team results, we could start by assigning small management tasks to the younger team-members and at the end involve them into the more complex tasks.
After all, how do you became a manager ? how did you became a Sr developer ? how did you became an Engineer ?, it was by doing, we were not selected genetically right?.
I deeply believe that successful managers have some special sauce to make a team succeed in each task they take, and one of the things that is for sure inside that special sauce is inclusion, it includes recognition and a bit of challenge, and these are base things to make someone better.
Make your team manage itself, hey, who could do it better ?.
In part one I talked about what refactoring is and all stuff related to that. In this post I want to show you how refactorings are related to frameworks and give you a real example of their use.
Frameworks were design to make your life easier in some way, and they should fit to solve your problems. Nowadays developers rarely build apps from scratch, we use frameworks according to our needs to speed up construction, testing and delivery. You realize that get used to a framework doesn’t mean you are except from live without code smells. You can actually apply refactoring techniques using the components and elements those frameworks provide.
To give you an example, last week we were working in an app which was built using Ember.js framework, while we were in a manual code review activity, we found some duplicated code into three route components.
So, in a nutshell beforeModel hook validates if an user has been logged in, and if not then it redirects to login page. There is obviously a duplicated code smell winking its eye, we need to move that code into “something" that allows us to reduce changes to this logic be replicated three times or many more if new routes are defined and need to be constraint by this logic.
Remember previous post I mentioned code smells can be solved by using refactoring techniques? Move Method refactoring is the one I chose.
Before I dig in it, a question emerges, where do I put that code i’m going to move?, here is where my framework understanding should be highlighted. Ember.js introduces concepts like Mixin and Services, which were my first options to use, but then I notice Ember uses routing hierarchy delegation and it is like implementing inheritance between routes. I took latter approach, the reason was because it was a routing problem and that piece of code should be also managed at the same level, there are not another components in the app that use that kind of logic so I discarded mixing and services. ApplicationRoute is the root parent of all routes so I applied move method refactoring to put my code into it. I started applying move method in one route, tested it and then move on the next one. Here is the result.
The other routes don’t need to define this method anymore and it is also located in just one place.
To conclude, there are a few things I want to highlight about this exercise.
First thing is whatever framework, programming languages, even markup languages you use you are not except from introduce some code smells, this is something natural that happens most of time, the key is to learn to detected them and mitigate them using refactoring techniques.
Second thing is you must have a basic understanding about the framework you use, get knowledge about overall components, what are their roles, many of frameworks were built following some architectural patterns so they can make your life easier, when applying a refactoring take in account framework components first, then see if it can be solved by using low level elements like classes, objects, etc.
Finally, dedicate yourself at least 15 min of your day to learn about refactorings and code smells. For every code smell you learn try to find in your code if it exist, then apply the refactoring to mitigate it, this is the best way for training and put yourself into a different mindset. Practice and practice.
Keep Learning, Keep Applying…
Let’s imagine you want to visit a friend in town but you don’t know where he or she lives, so you call him/her and ask for his/her address. The address becomes your target place, it’s the place where you want to go. When you are about to decide to move, you think, what path should I take so it can lead me to my destiny?…So your options are probably based on less time path, or more secure path, or nearest path. After you decide to use a path, you move and follow it until you end at your destination (your friend’s house).
That kind of thinking is a little bit related with the concept of refactoring. Imagine now that the situation is not to visit a friend but to extract a piece of code in your app. With that piece of code, you want it to live in a new method, the new method now becomes your target (the place where you want to go). So you think again, what path should I take to put that piece of code into a new method in a safe way?…
Wait, safe way?, extract a piece of code can involve a lot of things, you could extract local variables which are used later in the method you extract your code from, code you extracted can also depend on some variables defined before from the code you extract, so this process should be done carefully as current behavior should be preserved.
A refactoring is a prescription of a safe path you need to take in order to solve a particular problem in your code. I like to think about refactoring not as an activity where you remove duplicated code or make your code easier to understand in a deliberate way, a refactoring feels like a guideline, it is a step by step guide to transform your unhandled piece of code into a handled one in a safe way, without affecting code behaviour.
Following the example I mentioned earlier, supposed that the code I want to extract is related to outstanding calculation:
which path should I take? how should I extract that code? well, there is a refactoring called Extract method with the mechanics(path) to extract a piece of code into a method in a safe way. I use this refactoring almost every day and it has became pretty natural to me to apply. After applying Extract Method Refactoring my code looks like this:
Look that code I extracted depends on customer variable. customer is just used to read some of its attributes (orders), so I passed it as a parameter to the function calculateOutstanding. However, outstanding variable is calculated and then it is used later in print details section inside printFor function, that’s the reason why it’s returned.
Extract method is just one of many refactorings existing. Every refactoring has a template, if you click on Extract Method link mentioned before, you’ll see the first thing is a definition about that refactoring, and coming next you’ll see a before and after refactoring class diagrams, which means “go from this start point to this target point”, there is also a motivation to use the refactoring, mechanics(path or step by step) for applying it and some examples.
Nature is full of balance and contrast…
There is no existence of light if darkness would not exist, we would not talk about war if we don’t know what peace means, we inhale oxygen produced by plants to exhale carbon dioxide which feeds plants. So, we can not mention refactoring without talking about code smells. Refactoring would not exist if code smells do not emerge.
In a simple way, code smells are those “things” that make you feel like there is something wrong in your code. When emerging, they can make your code hard to change or understand. Some of us recognised duplicated code introduced in an application. Duplicated code is considered as a code smell because of the impact it can cause when changes need to be done. You will need to introduce the changes as many times as the code is duplicated. Here is a list of some code smells you can probably deal with:
Duplicated Code Long Method Large Class Long Parameter List Divergent Change Shotgun Surgery Feature Envy Data Clumps Primitive Obsession Switch Statements Parallel Inheritance Hierarchies Lazy Class Speculative Generality Temporary Field Message Chains Middle Man Inappropriate Intimacy Alternative Classes with Different Interfaces Incomplete Library Class Data Class Refused Bequest
Code smells are out of scope for this post, I’ll talk about them in another entry, I think they are as important as refactoring. What I really want you to know is that refactorings help to mitigate a code smell, when a code smell is detected, there is at least one refactoring technique to make it disappear.
Refactorings can be applied in an incremental approach. You start applying one small refactoring in a method, then a medium one in a class or object and after that you can apply a bigger one between two classes or components. This is an approach used in emergent design, the result for this process is to accomplish a more robust design which can suit to a pattern design. I recommend you take a look to Refactoring to Patterns by Josh Kerievsky.
To conclude, refactoring (the verb) is an activity we as developers must consider to practice and learn more about it. Code smells are inherent attributes when developing software, they always seem to appear, learn to detect them and mitigate them using refactoring techniques require some practices and discipline, but the result is a code that looks cleaner, easy to change, easy to mantain and easy to extend.
Keep learning, keep applying.
In 2013, Organization for Economic Co-operation and Development accepted Colombia as a candidate to become an active member of this privileges countries group. If Colombia accomplishes all the requirements for membership requested by OECD, it would be part of “the best practices club”, where countries with better perspective and better performance in social and economic fields help each other to improve their public politics quality, which means more investment, more employment, more capability.
There had been great progress in some areas along these two years. One of the greatest progress made in Colombia is related with IT investment. With help of ICT ministry and FITI, some programs were developed to help entrepreneurs to create businesses around IT technology, programs to capitalise IT professionals which offer free certifications, free scholarships for MBA and PHB degrees related to IT industry, I+D+I, just to name a few ones.
An info-graphic emitted by ICT ministry for the last four months of 2014 shows how IT technology has improved its use and capability to coverage almost the whole country. Also, statistics from the same source show how GDP had behave in a decade thanks to IT investment.
So things look good for Colombia in IT subject, but there’s a long road to follow and good quality software production has been the need nowadays.
In Colombia software investment had grown up around 43% in the last decade, estimated in USD 6’200’000,000. Today, exists a lot of demands for software production in Colombia, many companies decides to offshore software production because of the lack of companies with good quality software production or because they are too expensive, So they decide to outsource with Indian or Chinese companies with some maturity in software production and maybe because they are cheaper ;).
On the other side, the great news is that this situation is changing, we as local software producers have a big social responsibility on what we do and we’re doing a lot of improvement in quality of software production.
Software Engineering Institute a.k.a SEI, emitted four months ago a report that keeps me motivated and dedicated to get better in this business (and also proud to be a colombian :), yeah I love my country). Colombia got the first place as the country with more software development companies which applies the best practices in software engineering in south america, according to the Capability and Maturity Model Integration a.k.a CMMI. This means Colombia is getting mature about the way it develops software and it’s making it more competitive in the business.
This is a reality, Colombia is developing good quality software applying the best practices according to SEI. I hope the number of software development companies in Colombia with good quality software production keeps increasing as we follow a continuous improvement process, and maybe someday when Colombia becomes an active member of OECD would be prepared to be the reference in software development.
Keep Learning, Keep applying…