Hackerman's house

Here will be shown the evolution of Francisco's programming skills.

Lisp: Good News, Bad News, How to Win Big

Lisp: Good News, Bad News, How to Win Big is an essay written by the American computer scientist Richard P. Gabriel in 1991. At that time, he worked a lot on the Lisp programming language. The main topic of the essay is the advantages and disadvantages of that programming language, and how accepted it was by the programmers, as well as some of its uses.

Lisp’s successes


One of the biggest successes in Lisp is that there is a standard Lisp called Common Lisp. This wasn’t considered the best Lisp but it was the one ready to be standardized. There was a Common Lisp committee formed by users of different Lisps across the United States; Common Lisp was a coalescence of the Lisps these people cared about.


It used modern compiler technology of that time, so compared to older Lisps it had a very good performance. It also had multitasking and non-intrusive garbage collection, both were great features that weren’t possible before that time.

Good environments

The environments had a lot of good qualities like windowing, fancy editing and good debugging. Almost every Lisp system had these kinds of environments; a lot of attention had been paid to the software lifecycle.

Good integration

Lisp code would coexist with C, Pascal, Fortran and other languages. Lisp could invoke them and be invoked by them. This was useful to manipulate external data and foreign code.

Resultado de imagen para c language

Object-Oriented programming

At the moment it had the most powerful, comprehensive object-oriented extensions of any language. This was really important because OO was the new trend.

Lisp’s failures

The rise of worse is better

One of the biggest problems of Lisp was the tension between two opposing philosophies. The right thing and worse is better. Lisp designers used the right thing, while Unix and C designers decided to use the worse is better. In the long run the worse is better philosophy resulted to be better because it takes a lot less time.

Good Lisp programming is hard

In Lisp, the developers could write really poor code that still worked, this meant that if the developer didn’t make enough effort to write good code, the program would work but it would perform really poorly.

Resultado de imagen para hard to program

Non-Lisp environments catching up

The Lisp environments didn’t progress in years, while languages like C were evolving really fast and surpassing Lisp.


Code revision

Code review (also called peer review) is a software quality assurance activity in which one or more developers check a program by reviewing and reading parts of its source code. At least one of the reviewers must not be the code’s author, the purpose of this is to have another point of view, and different ideas to judge the code in a more objective way. The people performing the checking (except for the author of the code) are called reviewers.

Resultado de imagen para peer programming

The main objective of this process is to detect quality problems, although it can be used to reach more goals. Better code quality: improve the readability, maintainability and understandability. Finding defects: finding performance problems, security vulnerabilities among other flaws. There are many more goals that can be achieved through this process, but the general idea is to create better software and to avoid errors.

Types of review processes

Formal inspection

This is the traditional method of review. Software developers attend a series of meetings where the code is reviewed line by line. This method has been proven to be very effective in finding defects in the code.

Regular change-based code review

This is a more lightweight type of code review. This type uses something called Version Control, it is basically a system that records changes to a file or a set of files over the time. Github is one of the most popular applications that does this; the developers are constantly checking the changes made by every member of the team. They can see who is the responsible for the code and they can check it, but they do not dedicate the time to read it line by line.

Resultado de imagen para git


OO and Agile

There are lot of agile methodologies, each one has its own practices and characteristics, but in general they share the same philosophy. These ideas were expressed in the Manifesto for Agile Software Development.

Resultado de imagen para agile manifesto

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

The origin of these methodologies arises in 1990s in a world shaped by two major influences: Object-Oriented programming replacing procedural programming as the programming paradigm favored by the industry; the other influence was the rise of the internet. This situation made that the requirements started to rapidly change and shorter product life-cycles were required; this was incompatible with the traditional methods of software development. There was a need for new methodologies that could adapt to this new world.

Extreme programming

Extreme programming is a methodology which is intended to improve software quality. It advocates frequent releases in short development cycles; it uses checkpoints at which new customer requirements may be added. Other main elements of this methodology is pair programming, extensive code review, unit testing of all the code, avoiding to develop features until they are actually needed, and one of the most important ones is constant communication between the client and the programmers to assure all the requirements are being fulfilled. The origin of the name is that traditional software engineering practices are taken to extreme levels, such as pair programming that is basically extreme code review.

Resultado de imagen para extreme programming


Test Driven Development

Test Driven Development is a software development process that repeats very short development cycles, the requirements are turned into specific test cases, and the software is improved in order to pass these new tests. This way all the software is proven to meet the requirements set. One of the main responsibles for this methodology is Kent Beck who rediscovered the technique.

A Test Driven Development cycle consists of a series of steps. According to the book Test-Driven Development by Example these are the steps.

Add a test

Each new feature begins writing a test. The test defines a function or the improvement of an existing function. The developer must start by fully understanding the feature and its requirements. Some of the tests can be updates of an existing test. The use of tests before starting to write code lets the developer to focus on the requirements while writing code.

Run all tests and see if the new test fails

In this step the existing code is proven to see if the new test is passed. If the existing code passes the new test it means that the test is useless or flawed. The new test should always fail because there should not be code that fulfills the requirements yet.

Resultado de imagen para tests

Write the code

The next step is to write the code to pass the test. It is not that important that the code is elegant or really well written. The most important thing is to pass the test. One thing you should consider is that the code must only fulfill the test and not add more functionality beyond that.

Run tests

If all test cases now pass, then the new code meets the test requirements and doesn’t break any existing features.

Refactor code

The last step in the cycle is to clean up the code. Move it when it is more convenient according to the structure of your system. Eliminate duplication and in general follow the OO principles you already know. Try that your code is readable and maintainable.

Resultado de imagen para code


As you are advancing in this process, repeat all the steps in the cycle for every new feature you need to develop.


Testing in OO

Testing takes a big part in software development. It is important to know how to do the testing so that you can solve the problems presented and spend less time in this stage.  Object-Oriented testing is different from traditional testing. The root of this differences is that traditional programming consists of procedures operating on data, while OO testing treats with objects that are instances of classes.

Resultado de imagen para object oriented

Testing levels

There are several testing levels when you are doing OO testing.

Algorithmic level

Each module or method of every class should be tested in isolation.

Class level

Every class should be tested as an individual entity.

Cluster level

As classes are collaborated or integrated to form a small subsystem or cluster. Testing each cluster individually becomes a necessity.

System level

At this level, interaction among the clusters is tested.

Test Cases

Methods to design OO test cases are based on the conventional methods, but the should encompass some special features to that they can be used in the object-oriented environment.

  1. It should be explicitly specified with each test case which class it should test.
  2. Purpose of each test case should be mentioned.
  3. External conditions that should exist while conducting a test should be clearly stated with each test case.
  4. All the states of object that is to be tested should be specified.
  5. Instructions to understand and conduct the test cases should be provided with each test case.

Resultado de imagen para testing

Testing Methods

State based testing is used to verify if the methods of a class are interacting properly with each other. The basic idea of this method is that an object is created, and several methods are invoked to see if the object is changing states the way it should.

Scenario-based testing is used to detect errors that are caused due to incorrect specifications and improper interactions among segments of the software. The structure of this tests requires a condition under the scenario runs. You have to define the goal, steps and the final condition under which the goal is achieved.

There are a lot more tests that can be done in OO design but these are some of the most important ones.


Verification and validation

These are two different processes utilized to test if the software we are producing satisfies certain characteristics. Both are directly related with what the client wants to build. Let’s see the differences between them and why both or them are important in the process of building great software.


Verification is the process of evaluating work-products of a development phase, this doesn’t evaluate the final product. The evaluation done decides if the software satisfies the specified requirements of that phase.

Are we building the product right?

Verification is done trough reviews, walkthroughs and inspections. These check if the software satisfies each of the requirements it should.

Resultado de imagen para verify


Validation is the process of evaluating software at the end of the development process to determine if it satisfies specified business requirements. It basically evaluates if the software does what the client needs, it is directly related to the specifications done at the beginning of the project, if these were wrong in the first place then the software won’t be validated.

Are we building the right product?

There are two ways to perform software validation, internal and external. In the internal way it is assumed that the goals of the stakeholders were correctly understood, and if the software meets the requirement specification then it is internally validated. External validation happens when you ask the stakeholders if the software meets their needs.

Resultado de imagen para validation


Chapter 10 HFOOAD

I have finally finished this book about software analysis and design. The last chapter was like a big recapitulation of all the other chapters in the book, its purpose is to explain how everything is connected and part of the same process; a process that can be used over and over to develop great software.

First you have to figure out what the app is supposed to do, to get this part right it is necessary a lot of communication between the developers and the client. A good way of writing down these features is as a list, at this stage you must understand each of the features and make sure that you have all of the key features the client wants.

When you have all your features you can start working on the use cases. Use cases reflect how the system is used. It consists of many steps on how the action is done; it includes subjects and verbs as well.

Once you have all your use cases you can start working into smaller pieces of functionality. Modularity is really important in this step. Take your time defining how to break up the system. When you are breaking up the system you should consider that each thing has to have a single responsibility, make sure your classes use this principle in order to have a better design.


Photo by David Douša

When the big picture is defined, it’s time to dig deeper in specific parts of the system. Understand the part of the system you are working on and do use cases for that. The general understanding of the system lets you work on the specific parts of it.

Domain analysis consists in determining the operations and the classes that are going to be in the system. It is all about how the system is a solution to the problem, and how it is going to work to be a viable solution.

The next stage is the preliminary design where you should work in your class diagrams, this contains a lot of useful information for the implementation, each class has attributes, methods, and the diagram contains the inheritance and relations between the classes.

All the steps we have done until this point are going to let us do the code in no time. The class diagrams let you create the basic structure of the code, including the attributes and the methods of the class. The domain analysis facilitates the writing of the code inside each method, because we understand clearly what each of them does. In this case the code is written in java, but you can adequate to the language you want, take into consideration that each language has its strengths and weaknesses. After finishing the implementation of one specific part of the system you have to go back to the requirements and start working in the next part of the system.


Photo by adi_dahiya

The last part is the delivery of your final product. Make sure you are in constant communication with the client to make sure you are doing what they need, and not some weird stuff that you understand.

Classes to code

If you have read my blog up until now, you should know the basics about software design, and specifically about the use of UML in this area. Let’s see how to take advantage of all the analysis and design we have done. The class design that we already know how to do can be converted into code that will be the actual implementation of the system.

Resultado de imagen para class diagram

The quality of the diagrams used has a direct implication on how to translate it into code. Diagram classes are object oriented, so it may be convenient for you to convert these diagrams into a object oriented language; this will allow you to keep the identity and functionality of the system you design; if you consider that using a non-object oriented language is more appropriate in your own case feel free to do so.

It is important for you to have a profound understanding of your system and your diagrams before starting to code. You will be able to see that the class diagrams offer you a lot of information to that you can take advantage of; the first example is the attributes you will need to initialize in your code. The method’s name gives you a basic understanding of what you have to program. Even the inheritance is specified within the diagrams, all you have to do is implement all the design you already have. Just take your time and select a language you are familiarized with.

Resultado de imagen para coding

As we can see, the hard part is already done when the analysis and design is finished. The implementation is just a translation of what we already know about the system.

Chapter 8 HFOOAD

Design principles

This chapter talks about a topic I already discussed a little in one of my posts. Design principles, which are guides that can be used to solve common problems when you are programming and allow you to do better code and without having that many troubles.

Imitation is the sincerest form of not being stupid

A design principle is a basic tool or technique that can be applied to writing code, the principal function of these principles is to make the code more maintainable, flexible or extensible.

The first one that is exposed it is really simple, it is called Open-Closed Principle, the basic idea is that the code should be extensible but not modified. A basic example of this is when you inherit from a class and you override an existing method. The behavior in the original class that is already proven won’t be affected, but it is useful for other similar implementations.

Image by Montillon.a

The Don’t Repeat Yourself Principle has to do with reutilization of code, when you are coding you have to abstract out things that are common and placing those things in a single location. First you need to detect the repeated code and determine which is the best place or class for that specific code. Then you erase the repeated code and just reference the code from the appropriate place. This is directly related to the requirements list, you want to implement each feature just once in the system.


Photo by Corliss NG

The Single Responsibility Principle. Every object in your system should have only one responsibility. You must analyze the methods inside a class to determine that they belong in there, that they are the responsibility of that specific object. If this isn’t the case, you need to move these methods to a more adequate class.

Resultado de imagen para single task

The Liskov Substitution Principle. Subtypes must be substitutable for their base types. It is about how to use inheritance correctly. You must be able to substitute your subclass with your base class without that much trouble. This principle allows you to detect bad use of inheritance, so that you can correct it. There are a lot of benefits of good use of inheritance.


Create a free website or blog at

Up ↑