Do you have more mistakes to suggest? Please feel free to add to the list.

Code review or software inspections are used to spot software errors, omissions and anomalies. The code review as the name implies is to look at the source code for errors and defects. To successful perform a code review a team of at least four people must be formed. The roles are:

1. Author – programmer: the one who owns the code and is responsible for fixing the errors.
2. Inspector: Inspects the code and/or the documentation to find errors – omissions.
3. Reader: Presents the code – documentation
4. Scriber: Writes the findings of the code review meeting.
5. Moderator: Manages the process and facilitates the inspection.

It is very important to keep any questions or comment to the code and not to criticize the developer. When done correctly code review is a positive experience for the team and a learning tool for all levels of developers.

In order to initiate a code review you must:

• Have a complete and precise documentation of the code under inspection.
• The team must know the coding standards that the organization uses.
• The code must be updated and must compile, prior to the inspection. It is a waste of time to inspect code that does not compile.

During one hour of inspection about 120 lines of code are reviewed. It is not recommended for the code inspection to last more than one and a half hours.
It is very important during the inspection to read and translate the code in plain English, based on the specifications. This way everyone can examine the logic and validity of the code.

Why should somebody prefer code reviews from testing?

• During the testing, there is a possibility that an error can mask other errors.
• Testing does not guarantee the code quality and code efficiency.
• In applications that use threading errors cannot be caught with testing but only with a thorough code review.

An advice to software project managers:
I would recommend planning time for code reviews in every project. Code reviews is a great way to mitigate code related risks during the early stages of development.

References and useful links

1. Rober Bogue (2006) Effective Code Reviews Without the pain http://www.developer.com/tech/article.php/3579756/Effective-Code-Reviews-Without-the-Pain
2. Josh Poley(2007) Best Practices: Code Reviews http://msdn.microsoft.com/en-us/library/bb871031.aspx
3. Sommerville I (2006) Software Engineering. Addison Wesley; 8th edition
4. Wikipedia (2010) List of tools for static code analysis http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis#.NET_.28C.23.2C_VB.NET_and_all_.NET_compatible_languages.29

This may sound like science fiction but the tools already exist to monitor and interpret brain activity. As stated by Alois Schlogl and Clemens Brunner in their article at October 2008 issue of Computer magazine, BCI’s purpose is to identify the user’s intention by analyzing only brain activity. In the article is presented the BIOSIG library which is a free and open source library of biomedical processing tools.

Recent research has revealed that Brain wave patterns can predict blunders. Neuroscientist Ole Jensen, Ali Mazaheri and colleagues Institute at the University of California, Davis, in collaboration with the Donders Institute in the Netherlands, has found a distinct electric signature in the brain which predicts that an error is about to be made.
By analyzing the recorded magnetoencephalography (MEG) data, the research team found that about a second an error were committed, brain waves in two regions were stronger than when the subjects correctly refrained from hitting the button. In the back of the head (the occipital region), alpha wave activity was about 25 percent stronger, and in the middle region, the sensorimotor cortex, there was a corresponding increase in the brain’s mu wave activity.

“The alpha and mu rhythms are what happen when the brain runs on idle,” Mazaheri explained. “Say you’re sitting in a room and you close your eyes. That causes a huge alpha rhythm to rev up in the back of your head. But the second you open your eyes, it drops dramatically, because now you’re looking at things and your neurons have visual input to process.”

Wireless EKG can help identify errors before they happen. If the technology is limited on these areas then it is used for something serving the common good. If the technology is used to monitor brain activity and spot “deviant” activity then we are not far from a thought police as described by George Orwell’s novel Nineteen Eighty-Four. In my opinion is in our hands to produce a manifest that will clearly state that Computer professionals and Software engineers should not consent into the use of this technology in general population but only on specific beneficial situations. (Air traffic control)

These three propositions were presented by Todd Fast, a Sun engineer, as reported by Paul Krill (infoworld, 2008).

The argument states that users, without the assistance of a professional, can create their web sites, their blogs and, by using applications such as Microsoft’s Access can even build their own applications. There are also many application generators that can be used to accomplish these tasks. Users can build all this software without the help of a professional engineer.

I say, this is good. Extremely good! From my experience, when businesses are using such type of software they soon need professional advice. They automate a task, see the benefits, but they have not the knowledge and the expertise to expand and integrate their system with another or even change it to adapt it to new situations.

You have to be really calm when you see a database created by a user. Among other omissions that is not normalized. Who needs normalization?

So stay calm! We are not yet in any immediate danger, till the next AI application comes out.

Reference
Paul Krill (2008). Developers’ role shifting from apps to platforms . Available at: http://www.infoworld.com/article/08/05/12/Developers-role-shifting-from-apps-to-platforms_1.html

Although in my opinion, many of the proposed areas are covered from the SWEBOK some areas are left uncovered. The role of an IT Architect is to understand the broader needs of the organization, to visualize the technological structure of the organization.

The IT Architect must know in relative depth the technologies she proposes. The IT Architect must also have training in management and in project management. These two areas are usually out of the job description of a Software Engineer.

The IT Architect will be responsible to communicate her architecture to both technical and non-technical stakeholders. I believe that an ArcBOK can complement the SWEBOK. It is easier that a Software Engineer becomes an Architect than a manager or a project manager becomes an IT Architect; because they have no technological training in depth .

We will see the results in the future.

References
IEEE Computer Society(2008). Guide to the Software Engineering Body of Knowledge . Available at: http://www.swebok.org/

Miha Kralj(2008). The Need for an Architectural Body of Knowledge. Available at: http://msdn.microsoft.com/en-us/arcjournal/cc505967.aspx

So what is Software Engineering?

The IEEE Computer Society defines software engineering as
“(1) The application of a systematic, disciplined, quantifiableapproach to the development, operation, and maintenance ofsoftware; that is, the application of engineering to software.
(2) The study of approaches as in (1).”

The SWEBOK knowledge areas are:
Software requirements
Software design
Software construction
Software testing
Software maintenance
Software configuration management
Software engineering management
Software engineering process
Software engineering tools and methods
Software quality
(IEEE Computer Society, 2008)

Creating software systems can be a very complex and demanding process involving many people. That requires substantial amount of time.

Other people from other disciplines do not easily comprehend what a Software Engineer does. Different people have different perception of our job depending on their viewpoint.

26 years ago I wrote my first computer program. It even now amazes me that people, with all that exposure in technology, cannot still make a difference between a Software Engineer and a computer technician or a power user. Medical doctors do not seem to have the same problems.

References
IEEE Computer Society(2008). Guide to the Software Engineering Body of Knowledge . Available at: http://www.swebok.org/