If You Must Know…

March 25, 2006

Well, if you must know, this guide is now part of The Mindset.



Just Caught a New Ride

March 16, 2006

It has been a while, but we are incrementally moving to a warmer location… where we will hopefully be more productive…
Want to find us…? Get into the right mindset (or just use Google)…

Coding Standard

December 5, 2005

A Coding Standard is a common document defining a set of simple, mainly structural, rules for writing code. Software companies tend to sanctify this document and see it as the ultimate answer to their quality problems.

In 1990, the Software Coding Standards Consortium (SCSC) has decided that words in the name of software-related consortiums should be separated with a ‘_’ character, and changed its name accordingly to Software_Coding_Standards_Consortium. This, of course, caused a major havoc in the industry because a large group of software professionals insisted that SoftwareCodingStandardConsortium is a much better name. Since then there are two major bodies trying to shape the future our industry.

Soon after the split, the Software_Coding_Standards_Consortium issued a new version of the ultimate galactic coding standard. The crown of this document was section 5.23.125a stating that “Class fields should be prefixed with a ‘_’ character?. The SoftwareCodingStandardsConsortium was not left behind, and two months later published its own version of the unified standard, which stated in section 4/D23/xWD that “Data members of a class should include a ‘_’ suffix. And so, the dispute went on.

In 1995 the entire software industry stood still when an underground group of developers who just started to use the emerging Java programming language created a new de facto standard: they ceased to use ‘_’ for class’ data members altogether. The Software_Coding_Standards_Consortium and the SoftwareCodingStandardsConsortium both felt threatened by this underground initiative, and decided to join forces. As a result, a new joint body was founded and named SoftwareCoding_StandardsConsortium. Analysts of the software industry claim, however, that this was too little too late.

These days, in the spirit of anti-globalization movements, every software developer believes it to be his basic human right to use any notation he sees fit in his code.

More Developers

December 2, 2005

Yet another common solution to another well-known problem.

The software industry is known for its tight-schedule projects. Numerous projects exceed their expected schedule, and some never come to completion (see: Deadline).

In a book published in 1992 called “Show Me the Way to the Closest Open Elevator Shaft: Thoughts about Software Project Management?, the author came up with a bulletproof solution to this problem. A project should start with the minimal personnel that might have a slight chance to do it on time. Then, as time passes and the project is expected to be late, more developers should be added to the team.

The author, Mark Mywords, claimed that the new developers on the team seem to motivate their colleagues into working harder and making an even greater effort to make it on time. The best recorded results, the book continues, are expected when 20% of the development team is added during the last month of development. Project managers were surprised to witness an increase in productivity of developers, in their motivation, and even in their general sense of happiness during this allegedly stressed phase of the project.

Since the book was published, many have tried to adapt this methodology to other domains. The most noticeable one was the attempt to add more people to the QC staff just before products should have been released. However, this attempt was not approved by project managers, since they found themselves in need for even more developers to fix the new bugs found by the additional QC people.

More QC

December 2, 2005

A common solution to a well-known problem.

Whenever a software product seems to be of poor quality, and especially when this fact is revealed only after the product is already delivered to the customer, the solution comes in the form of more QC resources.

Many in the software industry believe this is the most natural solution to the acute problem of software quality. Some, however, are still afraid that this will significantly increase the number of defects they should fix, and therefore prefer to have their customer reveal their defects for them. After all, the customer is a less experienced QC Engineer.


November 27, 2005

Integrated Development Environment.

A software development tool with capabilities such as visual designer, code generators, code formatting, auto-completion, etc. Many IDEs also support the addition of plug-ins to enable more functionality to be added by third parties.
Many people in the software industry still consider IDEs to be less productive tools for writing software, which should never be used by professionals.

In 2004, the VI Rules (VIR) underground group together with the better-known Only Emacs (OE) organization funded an extensive research about the alleged poor productivity of IDEs. Since both tools are open source tools, the research was funded using PayPal donations. Their goal was to prove that VI and Emacs are more productive than modern IDEs.

In this research, 786 developers were each given the task to develop a 400,000 lines-of-code e-commerce application with both Web and mobile front-ends. 30% of them used VI, as their development environment, 30% used Emacs, and 30% used either Eclipse or VS.NET. 10% browsed their favorite pointless humor site on the Web for the entire research.

The amazing results, which were never published, were secretly mailed to our Editor by an IDE vendor’s spy who infiltrated the VIR group. It seems that the average development time in the advanced IDEs group was 45% shorter than the average time in the VI and Emacs group. About 7% of the developers in the Emacs and VI groups were hospitalized due to an acute Carpal Tunnel Syndrome. The 10% browsing their favorite site never finished the task.

Because we conduct a serious research before updating this guide, we decided to do a follow-up on the research. We found out that each developer, was supposed to deliver his product to a randomly selected customer. Contacting these customers revealed an interesting fact: the customers who were supposed to receive the application from the Web-surfing developers were, on average, the most satisfied. All other customers were seemed to suffer some damages by the new product they received.

The impact of this revelation on the software industry is still to be seen.

The Difference between QA and QC

November 24, 2005

For years this question was the subject of numerous debates, discussions, and conferences where small tasty sandwiches were being endlessly offered to people from all over the industry wandering around with bags filled with cheap promotional little presents they received from official conference sponsors after standing in line for hours.

It was then officially decided in 2001 that the question is not that important, because both QA and QC are ignored for most of the time.

As a service for our readers, we offer the following definition, compiled by our top software expert: QA people tell you how you should do your job; QC people then show you why you did it badly.

Crisis Mode

November 24, 2005

A general term referring to any activity done to address an unexpected problem revealed at a highly inconvenient time, although it should have been anticipated and handled earlier.

Psychologists who studied closely the software industry found out that working in a crisis mode usually brings the best out of people. A group of researches from Boston who analyzed 2334 hours of security-camera tapes from 21 software companies concluded that when working in crisis mode, the average developer seems to be more relaxed, as if he feels this is the natural state to be in. Managers’ behavior, which was also analyzed in that research, also seemed to be more normative and humanitarian under a crisis. In fact, the entire team seemed to work better as one unit. Some teams enjoyed their time together so much that they voluntarily decided to work for longer hours without getting paid for it, and even order take away on their expense.

Soon after this research was published, major companies decided that they should encourage their workers to work in a crisis mode as much as possible, for everybody’s benefit, following the idiom: a happy worker is a good worker. Companies across the world started to deliberately create crises in order to motivate their developers and create a better atmosphere in the workplace. Some claim that the infamous Y2K bug was deliberately engineered into numerous products for that exact same reason.

The crisis mode research also affected the Human Resources profession. By now, it is already well established that developers who spent more time working in crisis mode, staying long nights at the office and trying to extinguish burning fires they have created are great candidates for promotion, simply because they are happier and more motivated. Developers who never experienced a crisis merely because they tend to do a good job to start with are labeled as troublemakers who lower their team moral. Fortunately, this is not a common problem.


November 23, 2005

The term Multitasking originally referred to the ability to run two or more processes on one computer at the same time. This is usually achieved using a context switch mechanism, which means that each process is executed for a given period, and then replaced by a different process, while storing the state of the previous one. This enables several processes to share a single CPU.

As technology advanced, it seemed that only one component in the process of developing software was left behind, and did not provide the needed performance: the human software developer. Naturally, this created an unacceptable bottleneck in the development process.

In the mid ‘90s, the Software Developers Productivity Consortium (SDPC), which is made out of top managers in the industry and even not a single software developer, has decided that software developers must catch up with technology and start working in a multitasking mode. The formal resolution that was published by the SDPC stated that “Software developers should be encouraged to work on several tasks at the same time. Where possible, the tasks should be completely unrelated to each other?.

With the success of the multitasking software developer, and the appearance of new hardware and software technologies, which increased performance even further, there are now a couple of new ideas waiting for the approval of the SDPC. The first is the dual kernel developer, which is expected to work simultaneously on two tasks using two PCs, two monitors and two keyboards. It is still not clear how the developer will operate the mouse when working in this configuration. The more advanced, yet futuristic, idea is the quantum developer, which is expected to handle infinite number of tasks at the same time.

The quantum developer idea raises many philosophical questions the SDPC will have to deal with. The most controversial one is: should we also demand managers to become quantum managers in order to be able to come up with an infinite number of tasks for their quantum developers. Most of the SDPC members tend to reject this idea on the claim that it is not moral to change the true nature of a manager.

Where Do You Want To Go Today?

November 22, 2005

A slogan used by a gigantic software company to promote their line of products.

Without any relation to this company’s products, the most common response of people in the software industry to this slogan was “somewhere else?.

In the history of the software industry, this era, which was characterized by an average employment time of 3.2 months before a worker decided to move on, is known as the wandering era. It was not long before it was replaced with a new and exciting era, from which we are still trying to recover: the wondering era.