Honey! It's not what it looks like: CODE REVIEW

Today I will start a new brand of posts: "Honey! It's not what it looks like". The idea here is to present some concepts about terms commonly used, but sometime misunderstood or just not clear enough to give a common ground for a good conversation.

Some confusion could raise when we use those kind of terms, you may use them expecting something and you get a completely different stuff; it is like in the every day life, you expect something in the other hand you get a raining of popcorn in your head, a dog barking or running at you and so on. The best we can do is go get a common ground about the terms, so every time that you see "Honey! It's not what it looks like" it will be me trying to discuss some of those terms.

As starter I will stick with code review. When someone comes to you and say: we need to do code review, what does it means? What are the expected outcomes from the code review? In a conceptual world which software engineering discipline is it included?
Let's just set the ground, every word or better group of word could have a locale meaning, I am not saying that those meanings are wrong, absolutely not, just saying that when those meanings are not clear, maybe you will get what you expect, but probably you will end up with popcorn in your head.

Looking at the Pressman[1] definition for FTR: "A formal technical review is a software quality assurance activity performed by software engineers (and others). The objectives of the FTR are (1) to uncover errors in function, logic, or implementation for any representation of the software; (2) to verify that the software under review meets its requirements; (3) to ensure that the software has been represented according to predefined standards; (4) to achieve software that is developed in a uniform manner; and (5) to make projects more manageable.", let's focus at item 1: the objective is to uncover errors in function, logic or implementation of any representation of the software, and the code is a representation of the software, as much a class diagram would be or a architectural design.
So from the Pressman definition we can say that a code review is a FTR applied at the code, which is a representation of the software, so from now on we can exchange the terms code review and FTR.
With the bases set: code review is a FTR, we can look at the other objectives of a code review; verify that the software meets the requirements, guarantee software standards, achieve development uniform and make it more manageable. Well that is perfect, right? With a simple review I can achieve all of it?

The answer is: yes and no, that is why: in order to achieve the desired output we need to have a proper input, for example the item 2. Do my software meets its requirements, yes a review could give you this answer, but to get the answer you need to have a proper requirement, otherwise how can I review my code? So when you ask for a code review and expect to have a item 2 attempted you need to give the proper input, and if you don't have a proper input, well then you have a problem.

I will not extend the discussing about the other items, but all of them require proper input to give you a proper output. I am not saying that the proper input is the 100% guarantee of a perfect output, but it is a good trail. In the other hand, it is not mandatory that all the output could be expected. You could say that I just want item 3 or item 4 or even another thing, but that need to be said.

The other element that you need to consider when you say –"I am going to do code review", it is how you are going to do that. According to Pressman[1] a FTR " is actually a class of reviews that includes walkthroughs, inspections, round-robin reviews and other small group technical assessments of software. Each FTR is conducted as a meeting and will be successful only if it is properly planned, controlled, and attended", are you planning to do all of it? If you are not then you need to understand that not all the outcomes from a FTR will be there for you or it will be valid.

Let's suppose that you don't have a meeting for the code review, how will you be able to achieve a development uniform knowledge in your team? A FTR when done by different people is a powerful tool to spread knowledge, sure we have alternatives like pair programming, but the alternatives should be investigated, and it is absolutely true that you need to do something, it doesn't come for free (again you don't do it properly the dog will bark at you).

There is alternatives to a FTR, to be more specific a FTR at the code exists, like the previous referenced pair programming, and there are others (you will find some references to other articles and web pages at the end of the post).
The important issue to consider is: what do I want to achieve with code review? Meet the requirement, standard code, spread of knowledge, manage my projects, etc; and from this point you need to start filling what those words mean. And remember, the experience proved that a code review done by more than one people with different knowledge about the problem is much more effective than a single person reviewer (ok I know that I should put some proper article reference here, so if you want I can bring it).

And before the end I would like to point to another detail concerning the FTR; where the FTR is placed in the Software Engineering disciplines. It is an instrument of Quality Assurance.
Some could say that in XP the pair programming is done by the developers and it is a code review; that is true, but it is still a Quality Assurance instrument. But why is it important? It is important because it shows what kind of purpose this tool has, it is not a testing tool, and it is one of the instruments to guarantee the quality of the code into the process, you should remember that one of the purposes of the Quality Assurance is to guarantee the quality of the product through a better process.
In this case the better process is achieved, for example, with the code knowledge spread across the developers. At the end while you are doing FTR you are also improving your software process, but it should be done properly and if this idea in mind.

As promised here it is a small list of articles about people discussing FTR, mainly code review, plus a website with a check list for code review[5] (could be a start for this kind of checklist):

[1] R.S. Pressman, Software Engineering – A practitioners's approach, MCGraw-Hill, 2001.
[2] T. Stalhane, C. Kutay, H. Al-Kilidar, R. Jeffery, Teaching the Process of Code Review, Proceedings of the 2004 Australian Software Engineering Conference (ASWEC’04), 2004.
[3] A. Vardhan, Learning to verify system, 2006.
[4] A. Harel, Prof. E. Kantorowitz, Estimating the Number of Faults Remaining in Software Code Documents Inspected with Iterative Code Reviews, IEEE International Conference on Software - Science, Technology & Engineering (SwSTE'05), 2005.
[5] Macadamian, Code Review Checklist, http://www.macadamian.com/insight/best_practices_detail/code_review_checklist/, 2010.

So remember that from time to time we need to recycle your dictionary, your common sense. Said that I will let you with the song, Time after Time, from the Brazilian band Dr. Sin.

Where is your coin?

Some time ago people used to believe that you should bury a person with a coin in his mouth in order to pay the ship (or at least to guarantee a good place in the ship) to the land of the death.
If even in the land of the death, in the other world, there isn't free entrance, imagine here, imagine in the software's land. In a nutshell: there isn't free lunch. But why all this death, lunch talks; are you hungry? Are you afraid of dying?

No, absolutely not! The question is that people still think as new technologies as a free lunch, something like, an all around solution. If you need speedy them you should let it go the versatility, if you want all around solution them forget the speedy and welcome to the complexity nightmare; the blanket is not big enough for everyone.

I guess that all of you already heard about those Agile things like XP, Scrum and others, they are not really the same thing but all of them propagate the idea of: postpone as much as you can the decisions, most of the time you will realize that they are not needed or you will have the enough knowledge to do it right; I completely agree with that (by the way it doesn't means that the decision should not be made or it should be a no meaning decision, like a lot that we see around).

And them you come to NoSQL alternatives, quite flexible and it seems to fit so smoothly that it is like a temptation. No schema, you are so free to change it that you can even have different versions of data in a productive environment, really nice. Do you remember that we need to give the coin to the punter? Well, the NoSQL is a really light because of the simplicity of its schema, no rules, but it has a cost, the queries.
Once you go for this kind of solutions you need to pay in the queries, you don't have the power of the relational databases here. If in one end you don't need to think about the schema in the early beginning at the other end you DO need to think about how you are going to look for that information in the future.

Most of those solutions requires you to duplicate data if you want two different queries at the same time, or you need to create a view that will be your query, or simply no query at all, just a sequential access to the data (in a predefined order). The benefits? Fast, light, easy to distribute, but you need to pay a price for that.

So are they not really going to work in the real world? Absolutely not! Do not misunderstand me, they have a place, and I guess a big one. But we need really to understand what kind of application we are going develop, in the early beginning to know if it fits or not, and to address the needs of the technology.

The point here is: you need to know with whom you are dealing; do not take only the nice words of Agile and NoSQL; otherwise you will fall in the sing of the sirens and your ship will crash the rocks of reality.

As usual I will let a link here, I guess it will help you all to clarify what I am talking about the drawn backs of the NoSQL technology (in this case Cassandra): WTF is a Super Column

Jazz

Today I am going to move from the usual coding subjects to something more related to process. I guess that the Rational suite is well know for most of us, together with the Rational suite there is the Unified Process concept (in a creational point of view: first the man created the Unified Process, he looked and it was not that good, then he created the RUP and it was ok, but the desire for more make him create the Rational suite – and now he is ashamed for the rest of his life).

I am not here to discuss the quality of the Rational Suite (which I am not a fan) or the Unified Process (which I am sure is misunderstand process), but I want to bring to you a new initiative from IBM the Jazz.

According to the IBM Jazz website, this initiative could be define as: "…Jazz is an initiative to transform software delivery by making it more collaborative, productive and transparent, through integration of information and tasks across the phases of the software lifecycle".

Jazz is a set of concepts and, of course, a group of IBM products; you can think about those products as an evolution of some Rational products. But in this case I guess with some major differences (in the direction of the Sun): it has an open source architecture, which means that you can plug any external software to work with it (open ground to open source software) and it has a community portal. The portal has a lot of information, so you do not get stuck with some guru-guys saying what should be done and what not, no more high cost guys or information blockage. I am not saying that everything is for free, but the community can grow by itself.

A nice set of products, the community process is not new, but is always good to see people getting into it, mainly in the area of process where the community idea is not really easy to accept. But the most important part, in my humble point of view, is the move to some agile process. You absolutely do not see anything in the Jazz.net saying about Scrum, Agile, and so on, that is absolutely true – what is ok because it is just products and you can use it with the process that you like most.

If you watch the videos in the portal you will notice what I am talking about. For example this video: the Collaborative ALM Demo – The Jazz Revolution tells a nice story that has a happy end because of the Jazz. But is it true? I don't think so; I have counted 2 times the agile word, 2 times continuum integration and 14 times the Iteration word, plus N points in this iteration and so on. If it is not something similar to Scrum I don't know what it is.

The point here is: nice tools help but do not solve our problems and the same time that short iterations, real scope review, communication, real information that serves as input for the work, test cases and other stuffs that makes the big wheel turn helps much more.

In a more philosophical way of thinking: a beautiful ring (the tool) is still just a ring without a gentle hand (the process) to have it, and I can imagine much more uses for a gentle hand than to a ring.

Initial Experience

Yesterday we "finally" deployed in production a version of the software that took quite a long time to go. And thinking about it come to my mind a article that I read in IBM portal talking about Initial Experience.

When we find ourselves developing software for "internal" costumers is quite easy to forget that your software could cause a good/bad impression at the user, mainly if it is a brand new software, or those long time expected releases. The common thought is: why should we botter about it when the costumer has just one option: accept it or accept it; but thinking in this way doesn't make your product better I can insure you.

A serie of articles from IBM bring some ideas about this Inital experience of the users with the software. The initial experience is just a relation between the user expectation with the product and what he really get from it.

For sure it is not a simple matter, because we have differente level of users, uses of them in the product and so on, for example: is this user a novice or an expert?
Which are the factors that we should consider in this inital experience? And so on.

So take a look in the articles, read about it and next time that you are going to make a deploy of something new, think about it. It could be the difference between a easy life in the following weeks or the opening of the hell's gates.

IBM Design: Inital experience

And remember: the first kiss is that really matters ;-) Nice weekend.

Guidelines!?!

This month at the working place we could manage to promote some Design Pattern training. The really basic about the patterns, a quick and dirty overview of Gof's patterns.
I am not here to discuss the importance of the training, how basic it could be, if people should go to learn it by them self or whatever. I am here to discuss the results of the training.

We have managed to make 2 days in 2 followed weeks, and with 2 different groups. Most of the people thought that it was interesting and valid, and at the end of the sessions we come up with the discussion if we should continue with that or not, and of course what could be the next steps. A reasonable amount of ideas come up from, nice ones, other I think not that nice, but still ideas for next steps.

During the last session one of your colleagues talked with the Big Boss, about the ideas, with the purpose to give a feedback and collect the sponsoring need for the next sessions; but guesses what: an answer more less like this – "I believe that we can come up with some guidelines, publish it on the wiki page and people go there read and learn". Simple as that, why have we never thought about that? Unbelievable how stupid we are!

Or may be not? I fact I believe that not! Guidelines as the name (which in English is straightforward) are for guiding, are not for learning, usually in a guideline you have small sentences that gives hints for the people. Let's take an example: imagine a guideline like this "Prefer Abstract Factories over the Factory method and make them always return interfaces", what could happens if the reader does not know what is a Abstract Factory of a Factory Method or even an interface? From two one: or he will ignore it completely or it will take this guide line as a God message and follow is an immutable rule, something that if not done will make him end up in Hell!

None of these situations are beneficial; by far they are really bad. Guidelines are guidelines, rules are rules and knowledge is knowledge, both should exist but one cannot be exchanged by the other. Another point about guidelines, I don't believe in guidelines coming from a group of people (which in most of the places are a split department creating them as God writing the 10 Commandments) and releasing it. It should come from a common sense, and I am not only talking about programming, here you can include, analysis, requirements and so on.

I have already worked and participated of a projected that we have created immutable guidelines (or rules if you prefer a proper name) and it end up with a complex unnecessary structure – believe me a waste of time creating Action->that calls->Façade->that call->Business Objects->that calls->Dao->that converts to->VHO->is stored in the database, most of the time to be used for a internal web application that could have being solved with some Action->Dao thing.

So Guidelines are useless? Sure not, they are really useful for someone that can interpret them; otherwise people will lost faith on the guidelines and in the process and they will start to believe that it is a bunch of stupid rules for nothing. And at the end you will end up with zumbi-developers and a bizarre-code.

Horror plot in software development!

There are few things in this world that is worth to do over and over again, but I am but that falling in the same stupid errors is not one of them. I have just left a meeting where, for my surprise, people are happy to do it again.
I will put it as example: let's imagine that you have a car factory, your car is not the best in the world, but some people like it. Then you realize that every time that your customer wants a new item into the car (like ABS, radio, etc) you should almost rebuild the car.
After years one of your engineers come up with the brilliant idea: let's build a car that the user can choose what we wants at fly, so if he wants a radio he just tell us and suddenly the radio is there. Uou marvelous isn't it?
Then some more years to develop it, and you finally have the car! But as car stuffs increase people start to say: "you know, let's not make it configurable, it gives us a lot of problem". Sooooo guess what: you end up with the same car as before.
As I told you: the same mistake.

It is like an horror history: doesn't matter how much times do you kill Jason, he will always come back, there will be a lot of blood, a lot of people will died in the way, eventually we could have a happy end (the guy get the girl and that is it); but still a lot of suffering.

The point is: doesn't matter the end, we are still writing horror histories, and there will be blood! We should before changing the players start to think about changing the kind of history, way not action? Or a comedy or a even romance? You know: light stuff!

Going back to our original example: the car was made in the same way, the same approach, way should the result should be different? No way, it will be the same!

About software (yeap it is a software blog): if we keep looking at your application in the same way, they will always look the same. And I am not talking about the technology that we use for that, but the way that we do that.
It should be configurable, let's make it in a way that I could be configurable, not just adding properties. It should be multi environment, let's do in a way that it could be deployed multi environment; and so on.

To finish: in the next article I will add my idea of how a specific kind of enterprise application should be done. Why this kind? In the last years I have faced this kind of application all around and no easy approach to it.

Now you ask me: what kind of application? Well I am writing this post in a thriller way, so you will see it in the next issue ;-)

When the people that should know, doesn't know!

Today I’ve spent some time reading a set of documents at the company. It is incredible how official documents and manual has a lot of misunderstanding, things take lead to a wrong set of concepts and ideas.

It is important to have good concepts and solid knowledge, mainly to use the tools available for us. In this post I am showing small phrases and I would like you to read it carefully, you will face some amazing texts (by the way, I have translated them to English). 

The PowerDesign implements a Use Case Diagram and its objects using a OOM – Object Oriented Model. It was defined by the Methodology that all the Systems will have a OOM, called CAU (Use Cases), and all the functional requirements specification will be inside of this model.

First of all, you cannot implement a Use Case Diagram in a tool, what the tool does is: provide ways to modeling a Use Case Diagram and write a Use Case Specification. Next, Use Cases are not related to Object Oriented Modeling, they are related to UML (Unified Modeling Language), they are used to describe the responsibilities and boundaries of the system.

At the last, functional requirements are not Use Cases or vice-versa, when you put them in the same level you end up having a functional decomposition. Absolutely you don’t have a use case for each functional requirement. Use Cases represent what the actor wants from a system, not the functions of the system.

Lately we will see an example of it.

In truth, the Object Oriented Analysis is quite simple. Their concepts are closer to the human comprehension than the essential or structured analysis. In fact their functional definition is oriented to the user comprehension of the system, which doesn’t need to have any technology concept.

It is true that OOA is not related to technology concepts (I am assuming as technology concepts: programming languages, SQL, etc), as it isn’t true that the user can comprehend OOA. You should remember that it is a set of concepts and normally notations that you must know to understand it.

So at the end you cannot show it to your user, unless he know the concepts.

In fact their functional definition is oriented to the user comprehension… well I don’t know why it is true? What do we have is a highlight in the objects of the system, but if it is not well modeled the OOA will not show the user comprehension of the system. If you do the right thing doesn’t matter the tool, it will be right.

The benefits of the OOA are others like abstraction, where you can first look at a high level, and getting deeper and deeper as you know more about the problem scope (but I should say that it is not the only benefit).

The resistance to the Object Oriented Analysis happens because most of the people look at it as something advanced. In fact it has extraordinary concepts, for example, it is possible to automate the code creation 

OOA = automate code creation? What kind of insanity is it? You could say that from UML tools can generate code for you, but OOA, no way. From a language you could generate another language, doesn’t matter if it is OO or not.

Code generation is sure before OOA and it is not limited to that, for example: BPMN (Business Process Modeling Notation) is not OO and can be used to generate code.

But to create the methodology documents will be necessary only a small part of the Object Oriented Analysis, the Use Cases. That were already being made in the old documentation, although it was called as Requirements by functionality. 

I will say it again: Use Cases are not OOA. If someone makes just Use Cases he doesn’t need to know anything about object. And again: functionalities are not Use Cases.

All the modern tools for system modeling, among them the PowerDesigner, implement the UML

You don’t implement UML, you provide tools to draw, write, read, do whatever with UML, but it cannot be implemented.

In short, each system functionality must have a Use Case, describing how the user will interact with the system, in the strict context of the functionality.

Use Cases are NOT functions. A Use Case represents a situation where the user uses the system, to use the system a user can interact with one or more functions of the system, and a function can be used in one or more use cases, simple as that.

When you put them in the same level, you end up with a lot of small Use Cases that aren’t really cases. 

…The UML says that its name may have any amount of letters, numbers and most of the special characters. As we saw, to the Methodology the rules for naming are: CAU-[Verb in the Infinitive + Object]. Let’s take the Order as example:

                CAU-Make Order            CAU-Verify Order           CAU-Cancel Order 

First: Use Cases are not bind to specific objects. One of the first steps in OOA is to extract objects from a Use Case (when we are using Use Cases), so you cannot name them by their objects, mainly because a Use Case will interact with more than one object at the same time.

Second: Creating  Use Cases like Make Order, Verify Order, Cancel Order, Whatever Order means that we are writing functionalities and Use Cases. In this situation the user is interested in managing his Order, so we should have something like Manage Order; put yourself as a user and imagine what do you want from the system: you want something that allow you to manage your order, so it is your Use Case. For sure inside of this Use Case you will make, verify, cancel, delete the order.

In that situation you could have another Use Case that is something like Audit Order (it is reasonable that the user wants to get information from the Order and some processing on that, so you will have another Use Case).

As people say: not too much to heaven, not too much to hell.

 

An actor could be anything that communicates with the system. An actor could be the system user, but it could be an equipment, another system, a paper, and so on. The actor always interact with the system, but it doesn’t belong to it.

Actor are things that interact with the system, for example data bases are not actors (but they communicate with the system). And I cannot imagine how a paper could be an Actor. It is important to have it clear, otherwise you end up with Actors like, reports, screens, and things like that.

We should imagine an Actor as someone interested in your system, like the user, another system that receives data from us, and so on.

Test on demand???

It looks strange, but it is true! There is a company at USA that offers a test on demand.

They are a pool of testers, you registry your software that and they test it for you.

I don't know if it works, but it is a new idea.

Take a look at their site: uTest, also there is a article TestCrunch that talks about this company: uTest raises $5 Million More For Crowdsourced Bug Testing.

Interesting isn't it !?!

SPDS - Stupid People Developing Software

Yes, that is!!!!

We are just too stupid to develop good software, or even, to develop a software in the right way. I have just changed my work place, and I am still looking at super heroes all around. I don't see people worried to make the thing in the right way, just to make the thing like a super vilan.
Like a super vilan? Yes that is: instead of just killing the hero they need to create a BIG weapon and tortuous plan, just like us developing software.

If you need to create a file, why don't you create a validator for that, and use it to test? Noooo you need to send it to someone that will read, spend a day to give you an answer about. Or if you integrate with another system, why don't you start makeing good boundery tests? Noooo we still need to call everyone.

You it seens that things are only good when we need to spend at least 5 weekends working. The most that I like from Agile is fast deploy to the user, but no one cares about it; 1, 2 or even 6 months of development and a deploy in the last possible week, is it clever?

No it isnt't. Come on people let's put our brain to work, let's stop playing Superman, let's do you job as we are supposed to do: with wisdom, not just inteligence.

I'AM SICK AND TIRED OT IT!!!!!

Prototyping

Do you remember why the spiral development lifecycle was created? Exactly: because of the prototyping. At the beginning the idea was to prototype a little bit, develop a little bit, and this thing goes on...

Well I am not here to talk about the spiral development lifecycle, I am here to talk about prototyping.

There is a lot of ways to prototype a application, most of them are related to develop a preview of the software. But let's say that we want something more simple, and fast; basically a draw of the screen.

In that case most of us end up letting your Picasso goes out and get into some software like Gimp, Photoshop or even the PowerPoint. It is possible to draw a screen with them, sure it is, but we can use something born to it!

Here I would like to show you a Firefox 3 plug-in, free, light and enough for most of the tasks. But before saying the name, I would like to let a word: Scketching. If you need to search for this kind of screen draw it is the word.

Well let's go to the plug-in: Pencil Scketching. Download, take a look and enjoy!

Open Unified Process

Probably everyone have listened about Unified Process and all the variant process related to that. The OpenUP is also something based on the Unified Process:

What is OpenUP?
OpenUP is a lean Unified Process that applies iterative and incremental approaches within a structured lifecycle. OpenUP embraces a pragmatic, agile philosophy that focuses on the collaborative nature of software development. It is a tools-agnostic, low-ceremony process that can be extended to address a broad variety of project types

Take a look on this documentation, it can be a reference for you: OpenUP