Feedback lifecycles: How to reduce them in your developments. Why wait until the pull request to receive feedback?

Pair programming is one of the best tools that we have as a team when we want to speed up a feature and share the knowledge between the teammates. And it helps to reduce the feedback lifecycles.

In my opinion, the main advantage that the pair programming gives is that you reduce the feedback life cycle. How does it do?:

  • The answer is pretty easy, at the moment that you are doing pair programming, you are giving and receiving feedback because when you are doing pairing one of the devs are writing code and the other is helping him and providing feedback and vice-versa.

So, why do we have to wait until the pull request to have the proper feedback? Why do we have until the code review to share the knowledge?

If we use a traditional way of developing, where one developer writes all the code without sharing the information and receiving feedback. You are missing the opportunity in most of the cases of providing the best quality and a consensus solution. And maybe you can find some surprises in the latest phases of the flow.

In the beginning, Pair programming is a little bit difficult to use because the learning curve is hard and in most of the cases we aren’t used to working together during a workday or so. Also, Pair programming has some social and cultural connotation.

In my experience, using pair programming in my team we are improving the customer lead time and the local lead time in a 30%, furthermore, we use pairing not only the development phase but also in the refinement even in QA flows if it was necessary. Therefore in the team which I work, there aren’t silos and all the team members are more or less aware of the different features that we are developing.

Pair programming is one of the best tools that we have as a team when we want to speed up a feature and share the knowledge between the teammates. And it helps to reduce the feedback lifecycles.

In my opinion, the main advantage that the pair programming gives is that you reduce the feedback life cycle. How does it do?:

  • The answer is pretty easy, at the moment that you are doing pair programming, you are giving and receiving feedback because when you are doing pairing one of the devs are writing code and the other is helping him and providing feedback and vice-versa.

Therefore, why do we have to wait until the pull request to have the proper feedback? Why do we have until the code review to share the knowledge?

If we use a traditional way of developing, where one developer writes all the code without sharing the information and receiving feedback. You are missing the opportunity in most of the cases of providing the best quality and a consensus solution. And maybe you can find some surprises in the latest phases of the flow.

In the beginning, Pair programming is a little bit difficult to use because the learning curve is hard and in most of the cases we aren’t used to working together during a workday or so. Also, Pair programming has some social and cultural connotation.

In my experience, using pair programming in my team we are improving the customer lead time and the local lead time in 30%. Furthermore, we use pairing not only the development phase but also in the refinement even in QA flows if it was necessary. Therefore in the team which I work, there aren’t silos and all the team members are more or less aware of the different features that we are developing.

Don’t forget, that you can’t force the people to do pairing, it is something that the team has to choose. All the members have to be comfortable with this. Otherwise, the pair programming won’t help the team to speed up the projects and at the end, it will be a problem.

Eventually, before finishing this article. I would like sharing with all of you one of the best articles that I have read about pairing. It was written by Martin Fowler: 

https://martinfowler.com/articles/on-pair-programming.html

How to catch an Exception with Spock

How to use Spock library

First of all, Spock is a unit-testing library which is usually used with Grails and Groovy. So you have to import the spock dependency in the Build.groovy or Pom.xml:

‘org.spockframework:spock-core:1.0-groovy-2.4’

group: ‘cglib’, name: ‘cglib-nodep’, version: ‘2.2.2’

(* Cglib library, it is necessary for mocking objects)

How to catch Exceptions with Spock

With Spock you can check everything you think, but in this article we are going to focus on Exception and its management.

In addition, you can catch an exception as follows:

In the test code you can see, the external service has been mocked in order to throw a NullPointerException, so our Payment service catch it and it will throw the final ExternalServiceException, as follows:

It is very common, the customer exception thrown has some attributes, for example:

How to check Exception attributes’

Threfore, you would be able to check all of the attributes which the Exception thrown had, as follows:

You can read other interesting articles like Defensive Programming and Resilient Systems. Also you can visit another interesting blogs like Mrhaki’s blog.

Best Regards

 

Defensive Programming and Resilient Systems

Although you have developed your software with TDD and your application has 100% coverage. It is likely which there will be some bugs in production environment, due to Murphy’s Law:

“Anything that can possibly go wrong, does”

As pragmatic programmers, we have to be critical with our code and our programming way, but sometimes this is not enough, and we have to try to guard our application of the production bugs, in addition our system should survive failures.

In my opinion, It is more important fail quick than the user or customer is waiting for any response of our application which never happens, besides it is very important to detect when the system fails, due to the error can be caught and fixed, also an email or another kind of alarm could be sent  in order to start to research what problem has happened.

Assertions

In my experience as developer in different Companies, when you have to do a report for some people, you have to create a file, you have to save it in some directory and perhaps, that directory is not still created or the application did not have permissions to write in it. So the process will fail and an issue will be opened.

For this reason, the unexpected conditions should be checked and Assertions (asserts) can be used. In our case, with an assertion or another kind of verification about the directory and permissions would have avoided the previous issue.

In the book Code Complete Second Edition, there are some rules regarding assertions that you should take in account:

  • That an input parameter’s value falls within its expected range (or an output parameter’s value does)
  • That a file or stream is open (or closed) when a routine begins executing (or when it ends executing)
  • That a file or stream is at the beginning (or end) when a routine begins executing (or when it ends executing)
  • That a file or stream is open for read-only, write-only, or both read and write
  • That the value of an input-only variable is not changed by a routine
  • That a pointer or element is non-null
  • That an array or other container passed into a routine can contain at least X number of data elements
  • That a table has been initialized to contain real values
  • That a container is empty (or full) when a routine begins executing (or when it finishes)
  • That the results from a highly optimized, complicated routine match the results from a slower but clearly written routine

An example of a groovy assertion would be the following:

 

On the one hand, if you want to use assertions in different places of your code, you can generalize your solution, this is an specific example.

On the other hand, be careful with the assertions in production environment, they can reduce the performance of your application.

Feature disabling

Another situation, that I have seen during my career, has been when you deploy a particular development which has been included in a  key component. If it is not working properly and you can not deactivate it.

A good practice, which you can use to avoid downtimes in your system, is feature disabling, although it is not the clearest solution. This technique consists in including an if statment in order to excute or not a part of code depends on any configuration.

Example:

 

If you ask me, the configuration should be in the database, because you can change it without deploying the application again. The other possibility is to use a properties file, but in this case you would need to reboot your application server, which  would produce a downtime.

Alert systems

Other problem, which you can find in production environment, is when you have a process which never finishes and you have no alarms or alerts. So… How can I know that the process has failed? Maybe somebody reminds you which you have a report who nobody has received or maybe not.

Hence It is very important to manage if a process should have finished. In this way, you can add an alert or timeout, when the process is running although it should have achieved successfully. Then you can research quickly, what it happens so as to fix the problem and restore the service.

During this article, we have talked about alarms, alerts and reports systems. All of them should be out our application to work when our system has failed, otherwise the IT team would not anticipate whether the system is working or not.

Another features of the Logs should be:

  • Readeable (By human or machine)
  • Do not allow break lines (New appenders Log4j2 or Logback can be configured to show the info in one line)
  • Do not mix different information
  • Show the important information (user ids, emails….)
  • Split the logs about the different services
  • Use daily rollings

Integration with other systems

Currently, almost all the application or sites are working with microservices or they have to connect to other services or databases. For these cases the health checks are very important, due to they detect whether the provider services are falling or not. Depending on their responses, the application will be deployed or not.

In addition, when your are connected with a provider service or database, you are going to consume their responses, and perhaps the data, which they provide, are not the best for your application or they are wrong, so you can create a barricade where you can validate and transform the data. With the new data your system will work properly almost always.

If your system detects an error data, you must decide what the system does with that data. In the Code Complete book, the author proposes some techniques which can help you to decide :

  • Return a neutral value: Sometimes the best response to bad data is to continue operating  and simply return a value that’s known to be harmless.
  • Substitute the next piece of valid data: When processing a stream of data, some circumstances  call for simply returning the next valid data. If you’re reading records  from a database and encounter a corrupted record, you might simply continue reading  until you find a valid record.
  • Substitute the closest legal value: In some cases, you might choose to return the closest  legal value, as in the Velocity example earlier. This is often a reasonable approach  when taking readings from a calibrated instrument. The thermometer might be calibrated  between 0 and 100 degrees Celsius, for example.
  • Log a warning message to a file: When bad data is detected, you might choose to log a warning message to a file and then continue on. This approach can be used in conjunction with other techniques.
  • Call an error-processing routine/object: Another approach is to centralize error handling  in a global error-handling routine or error-handling object. The advantage of this  approach is that error-processing responsibility can be centralized, which can make  debugging easier.
  • Display an error message wherever the error is encountered: This approach minimizes  error-handling overhead; however, it does have the potential to spread user  interface messages through the entire application, which can create challenges when  you need to create a consistent user interface.
  • Shut down: Some systems shut down whenever they detect an error. This approach  is useful in safety-critical applications.

In conclusion, we have to know which there will be bugs in production environment, but as pragmatic programmers we have to try to reach a system without downtimes and bugs, for these goals, the defensive programming tools are very important. However, if the bugs happen, try to solve it as soon as possible.

Although you use defensive programming,please you do not forget to keep on using  S.O.L.I.D, code reviews, tests and TDD.

References:

Joaquín Engelmo – Programación defensiva y sistemas resilientes en el mundo real

8 formas de mejorar tu vida gracias a los Logs

Code Complete Second Edition

Software engineer and knowledge

Usually when you finish your Software Engineering degree, you are a software engineer, but sometimes you are hired for a company as a developer and perhaps you do not just develop different tasks of an application. However it does not always happen in this way. Because you are not only developer, you are more than a developer. You can do more tasks, for instance designing how to program this issue or task or anything that you want.

We are software engineers and we have a lot of knowledge about developing, designing application, testing, deploying and other concepts. Also we have to improve our knowledge everyday since our world is always changing and improving, so that it is our duty in order to change and improve with it.

This blog has been created to research different concepts such as software patterns, clean code rules and different programming languages, and improve them. Currently, I am developing in Groovy and Java, also I try to use unit testing, S.O.L.I.D. principles and another good practices.
In internet there are a lot of sites where you can find enough information in order to learn a new rule or technique that you will use in your job or your own applications. I strongly recommend the following:

Finally, in the next weeks I expect to publish a new article about Structural Design Patterns. I hope this article and the followings help you in order to became a better software engineer.

blogSignature1

Refactoring and Good Code

Our code is not always the best one which we can do, and we have to assume this fact. Sometimes our solutions, designs, algorithms are not good, because they have been implemented with pressure due to a deadline. So it would be a good option in a close future to make a refactor in our code as part of our development. The main reasons are the following:
 
  • Improve code readability
  • Reduce complexity
  • Improve the maintainability of the source code
  • Improve extensibility
¿What is maintainability?
It is how difficult to fix a defect or add new improvement over one functionality which it has been created.
 
 
¿What is extensibility?
It is a system design principle where the implementation takes future growth into consideration. It is a systemic measure of the ability to extend a system and the level of effort required to implement the extension
 
 
¿How can I know if my code bad smells?
If your source code have some of the following symptoms or features, likely you code bad smells:
  • Code within classes
    • Long methods
      • The ideal length of a method has different opinions.
        In the Clean Code: A Handbook of Agile Software Craftsmanship, Robert Martin claims: “The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that. Functions should not be 100 lines long. Functions should hardly ever be 20 lines long“.

        Also Kent Beck claims that “Every function in his program was just two, or three, or four lines long. Each was transparently obvious. Each told a story. And each led you to the next in a compelling order. That’s how short your functions should be!“, so both have the same opinion.
    • Comments
      • On the one hand,  comments should not be necessary because the code should read as natural language and easy to understand.
        On the other hand, this does not always happen and comments would be necessary in order to clarify some aspect of the code, however you should not use these ones in every line since it would distract of the most important the code.
      • There is a good quote abouts comments of Robert Martin: “A long descriptive name is better than a short enigmatic name. A long descriptive name is better than a long descriptive comment.”
    • Excessive number of arguments
      • The number of numbers of a function or procedure should be as few as possible. If your function have a lot of parameters, maybe you are doing something wrong and you have to define your method in another way or perhaps you have to split it in more methods.
        Regarding the number of arguments Robert Martin has claimed in the clean code book: “The ideal number of arguments for a function is zero (niladic). Next comes one (monadic), followed closely by two (dyadic). Three arguments (triadic) should be avoided where possible. More than three (polyadic) requires very special justification — and then shouldn’t be used anyway.
    • Dead code
      • It means unnecessary, inoperative code that can be removed. 
    • Duplicate code
      • It is when the same code is used more than once. This problem is very important in the software development and we have to try to avoid it in order to increase the quality of the source code. DRY (Don’t repeat yourself) principle can be a good solution in order to avoid the duplicate code, if you want to know more information about this principle you can take a look this conversation among the Pragmatic Programmers Andy Hunt, Dave Thomas and Bill Venners about maintenance programming.
        Also you can check the following article DRY Principle
    • Conditional huge complexity
      • Conditional statements tend to be very complex, so that we have to try to simplify them. To simplify them, you can decompose the complex condition in some methods with proper names or you can use logic rules to reduce the complexity of the condition.
    • Wrong names
      • When a developer is writing source code, he has to choose the proper names for methods, variables and constants.  Usually, we want to save some time and we do not spend enough time to choose the proper names, because the names have to meet the following criteria:
        • Names have to reveal your intentions
        • Avoid disinformation
        • Good names length
        • Use one word per concept
        • Always code in one notation

      • Regarding the names of methods,  variables, classes and other elements Robert Martin in the Clean Code Book says the following:

        The proper use of comments is to compensate for our failure to express our self in code

        Also he claims other statements about the names:

        Functions should do something, or answer something, but not both.

        Methods should have verb or phrase names.”

        One way to know that a function is doing more than ‘one thing’ is if you can extract another function from it with a name that is not merely a restatement of its implementation.

        Goods examples of name for methods would be the followings: “handleXYZ”, “getXYZ”, “calculateXYZ”

    • Large class
      • A class should be small, as small as it would be possible. Regarding the Refactoring in Large Software ProjectsMartin Lippert and Stephen Roock talk about the Rule of 30:
        If an element consists of more than 30 sub-elements, it is highly probable that there is a serious problem:a) Methods should not have more than an average of 30 code lines (not counting line spaces and comments).b) A class should contain an average of less than 30 methods, resulting in up to 900 lines of code.c) A package shouldn’t contain more than 30 classes, thus comprising up to 27,000 code lines.d) Subsystems with more than 30 packages should be avoided. Such a subsystem would count up to 900 classes with up to 810,000 lines of code.e) A system with 30 subsystems would thus possess 27,000 classes and 24.3 million code lines.Maybe the Rule of 30 is a good guide in order to create clean classes.
    • Speculative generality
      • You should write code for the problem which you have found and you do not worry about tomorrow’s problems when these ones definitely happen. And you should not lose between “what if…”  and “in a future if …”.
        Within the Extremeprogramming practices, it exists a principle or good practice whose name is YagNi (YouArentGonnaNeedIt) and it talks about fixing the current problem and you do not think in unlikely flows.

  • Between Classes
    • Message chains
      • It happens when there are a lot of method calls in order to get some data or information of a object. These chains of methods call do the code depends on the relationship between unrelated object.
    • Middle man
      • Sometimes a feature of model can be used in bad way. For instance, in Object Model you can delegate the behaviour of a class in different classes, however it might be possible that one of these delegated classes do not have any responsibility, so it was wrong because it can not exist a class without responsibility. Be aware with the classes which are simply wrappers.
    • Shotgun surgery
      • It happens when you have to change a lot of pieces of your source code in different places to add a new functionality in your application.
    • Lazy Class
      • Every classes have a cost of money and time to understand and maintain them, so that if there are classes that they can not pay for your attention. Theses classes should be removed,  because they increase the complexity and maintainability of the project.
    • Alternative classes with different interfaces
      • It happens when it exists two different classes with different interfaces, but they have similar behaviour so you would make a refactor  using an adapter pattern to unify both interfaces.
    • Primitive obsession
      • The main cause for this problem is: “Use primitive data types to represent domain ideas”. It used to happen in a weakness moment, when the programmer decides to take the simple option instead of thinking another kind of solution more difficult than the previous one (For example: create a new class to represent the new field).

        Primitives are often used to “simulate” types. So instead of a separate data type, you have a set of numbers or strings that form the list of allowable values for some entity. Easy-to-understand names are then given to these specific numbers and strings via constants, which is why they are spread wide and far.
    • Data class
      • When it exists classes with only attributes and getters and setters methods, these classes are merely stored data for other classes, and these ones do not contain any additional functionality to work for they own.

        It’s a normal thing when a newly created class contains only a few public fields (and maybe even a handful of getters/setters). But the true power of objects is that they can contain behaviour types or operations on their data.
    • Data clumps
      • Sometime in different parts of the code there is the same group of variables close to the same object, so it is likely that this group of variables belong to the class of that object. Therefore you should to extract that variables to that class.
        The main reason of this problem is “the copy-pasta programming” and an poor data structure.
    • Refused Bequest
      • It smells when you have a class which inherits of another class but you do not use all the functionality provided by the bequest. So the hierarchy is off-kilter and the unneeded methods might go unused.
    • Indecent Exposure
      • Encapsulate is one of the most important features of the Software Design, in addition this one is not used properly and as a programmer when we design and develop a class, we publicity attributes or functionalities that they do not be shown. This fact contributes to increase the complexity of the design.
    • Feature Envy
      • This error helps to increase the coupling and duplicity code of the application which we are developing. It happens if a class makes huge calls to other class or classes so as to obtain data or functionality. In that case, it may move the functionality on data to this class as well.
    • Divergent changes
      • It occurs when somebody has made changes to class and the developer has included new behaviours that are very different that the previous ones. Therefore it contains too much unrelated functionality, so the developer should isolate that changes in other class.
    • Parallel Inheritance Hierarchies
      • While you are developing, you making a subclass of one class. Instead of making a subclass of another. So when you have defining the inheritance of a application, this structure has to be thought pretty well to avoid errors like that.
    • Solution sprawl
      • Sometimes, we have implemented a solution in order to solve a problem or perform a responsibility, which it has become sprawled across several classes. This fact is the result of implementing a quick solution or feature without spending enough time simplifying and consolidating the design.
 
 
¿What can I do in order to improve our legacy code?
Refactoring would be a good answer, in fact there are some techniques which it can be used to get better our source code. The most important are the following:
  • Composing methods
  • Moving features between objects
  • Organizing data
  • Simplifying conditional expressions
  • Simplifying method calls
Also there is some practices such us S.O.L.I.D principles, DRY principle, Boy Scout rule and others, which you can use in order to improve your quality code and may avoid doing a refactor.
 
Finally, in following articles we will delve into the different symptoms of the smell code to study why this happens, how we can fix it and how we try to avoid it.
 
References:

blogSignature1

Why should you use the Code Review?

First of all, I’m going to try to define what the Code  Review is.
What is the Code Review?
Code Review is a phase in the software development process in which the authors of code, peer reviewers get together to review code. Finding and correcting errors at this stage is relatively inexpensive and tends to reduce the more expensive process of handling, locating, making a refactor and fixing bugs during later stages of development or after programs are delivered to users.
Also there are other definition or comments about Code Review, one of the most important was done by Karl Wiegers in his article Humanizing Peer Reviews:
“Peer review – an activity in which people other than the author of a software deliverable examine it for defects and improvement opportunities – is one of the most powerful software quality tools available. Peer review methods include inspections, walkthroughs, peer deskchecks, and other similar activities. After experiencing the benefits of peer reviews for nearly fifteen years, I would never work in a team that did not perform them.
Opinion and data…
From my point of view, Code Review is necessary within a development cycle, because you can take a lot advantages:
  • Reduce number of bugs of a development task, and make easier the QA of this task.
  • It’s an opportunity to make a refactor and add improvements, because perhaps you have thought a solution but this one is not the best solution and perhaps, the peer reviewer has a good idea to improve that development, in addition to increase the quality of the code. Besides you can learn a new way to do the different develops.
  • Sharing the information among whole the team. In this way, all the team members will be able to do any task related to the project.
Furthermore, the importance of the Code Review is not only supported by my opinion, otherwise the book Code Complete , which has been written by Steve McConnell, provides objective data based on big companies experiences:
  • The average effectiveness of design and code inspections are 55 and 60 percent.
  • In a software-maintenance organization, 55 percent of one-line maintenance changes were in error before code reviews were introduced. After reviews were introduced, only 2 percent of the changes were in error. When all changes were considered, 95 percent were correct the first time after reviews were introduced. Before reviews were introduced, under 20 percent were correct the first time.
  • In a group of 11 programs developed by the same group of people, the first 5 were developed without reviews. The remaining 6 were developed with reviews. After all the programs were released to production, the first 5 had an average of 4.5 errors per 100 lines of code. The 6 that had been inspected had an average of only 0.82 errors per 100. Reviews cut the errors by over 80 percent.
  • The Aetna Insurance Company found 82 percent of the errors in a program by using inspections and was able to decrease its development resources by 20 percent.
  • IBM’s 500,000 line Orbit project used 11 levels of inspections. It was delivered early and had only about 1 percent of the errors that would normally be expected.
  • A study of an organization at AT&T with more than 200 people reported a 14 percent increase in productivity and a 90 percent decrease in defects after the organization introduced reviews.
  • Jet Propulsion Laboratories estimates that it saves about $25,000 per inspection by finding and fixing defects at an early stage.
Conclusions of a big study…
 
Some time ago,  IBM conducted a largest study on code review. It encompassed 2500 code reviews, 50 programmers, and 3.2 million lines of code at Cisco Systems. For 10 months, the study tracked the Meeting Place product team, which had members in Bangalore, Budapest, and San José. They got the following best practices:
  • Review fewer than 200–400 lines of code at a time

  • Aim for an inspection rate of fewer than 300–500 LOC per hour

  • Take enough time for a proper, slow review, but not more than 60–90 minutes

  • Be sure that authors annotate source code before the review begins

  • Establish quantifiable goals for code review, and capture metrics so you can improve your processes

  • Use checklists, because they substantially improve results for both authors and reviewers

  • Verify that the defects are actually fixed

  • Foster a good code review culture in which finding defects is viewed positively

  • Beware of the Big Brother effect

  • Review at least part of the code, even if you can’t do all of it, to benefit from The Ego Effect

 
Eventually, there is another way to do a code review, from my point of view, this is the pair programming. While one of the programmers develops the task, the other one corrects, helps and thinks to get the best solution. It is share information and get best solutions that the main target of code review is.
References:
blogSignature1