Visualize this, software bugs as coloured dots

Some developers, many many issues.
How does it look?

This comes straight out from our RnD department and shows how developers are connected to the various issues as they are submitted in our bug tracking system.

The issues and the developers are colour coded:

• The Teal circles are the developers and they are connected to their assigned issues.
• Green dots represent resolved and finally closed issues
• Red dots are issues which are only resolved but not confirmed - quality checks still pending.
• Purple dots - the fewer - are open issues.

Of course this is just a subset of our system to test a custom plugin under development for Gephi - (gephi is an opensource visualization platform following graph theory ).

The subset contains  issues that are mostly resolved or closed - that's why the purple dots are sparse :)

More to come as time allows - and this does not mean never :).

Developers and their issues...

Resign Patterns

The article titled Resign Patterns by Michael Duell was recently posted in a Linkedin discussion by Sergey G. , (Systems Architect).

The discussion  was about:

What's your favorite design pattern? Why? 

and among the very useful and informative comments the Resign Patterns one hit me the most. It is a humorous take on design patterns and how they are applied under development pressure.

I reformatted the article in pdf format and is now available from Google Docs.
You can read the original text below.

---

Resign Patterns

Ailments of Unsuitable Project-Disoriented Software

by

Michael Duell

Abstract

Anyone familiar with the book of patterns by the Gang of Four [1] knows that the patterns presented in the book represent elegant solutions that have evolved over time. Unfortunately, extracting these patterns from legacy  code is impossible, because nobody knew that they were supposed to be using these patterns when they wrote the legacy code. Hence, this work is a catalog of patterns for the masses. The patterns presented here represent abundant solutions that have endured over time. Enjoy reading the patterns, but please don't use them!

1. Cremational Patterns

Below is a list of five cremational patterns.

1.1 Abject Poverty

The Abject Poverty Pattern is evident in software that is so difficult to test and maintain that doing so results in massive budget overruns.

1.2 Blinder

The Blinder Pattern is an expedient solution to a problem without regard for future changes in requirements. It is unclear as to whether the Blinder is named for the blinders worn by the software designer during the coding phase, or the desire to gouge his eyes out during the maintenance phase.

1.3 Fallacy Method

The Fallacy method is evident in handling corner cases. The logic looks correct, but if anyone actually bothers to test it, or if a corner case occurs, the Fallacy of the logic will become known.

1.4 ProtoTry

The ProtoTry Pattern is a quick and dirty attempt to develop a working model of software. The original intent is to rewrite the ProtoTry, using lessons learned, but schedules never permit. The ProtoTry is also known as legacy code.

1.5 Simpleton

The Simpleton Pattern is an extremely complex pattern used for the most trivial of tasks. The Simpleton is an accurate indicator of the skill level of its creator.

2. Destructural Patterns

Below is a list of seven destructural patterns.

2.1 Adopter

The Adopter Pattern provides a home for orphaned functions. The result is a large family of functions that don't look anything alike, whose only relation to one another is through the Adopter.

2.2 Brig

The Brig Pattern is a container class for bad software. Also known as module.

2.3 Compromise

The Compromise Pattern is used to balance the forces of schedule vs. quality. The result is software of inferior quality that is still late.

2.4 Detonator

The Detonator is extremely common, but often undetected. A common example is the calculations based on a 2 digit year field. This bomb is out there, and waiting to explode!

2.5 Fromage

The Fromage Pattern is often full of holes. Fromage consists of cheesy little software tricks that make portability impossible. The older this pattern gets, the riper it smells.

2.6 Flypaper

The Flypaper Pattern is written by one designer and maintained by another. The designer maintaining the Flypaper Pattern finds herself stuck, and will likely perish before getting loose.

2.7 ePoxy

The ePoxy Pattern is evident in tightly coupled software modules. As coupling between modules increases, there appears to be an epoxy bond between them.

3. Misbehavioral Patterns
Below is a list of eleven misbehavioral patterns.

3.1 Chain of Possibilities

The Chain of Possibilities Pattern is evident in big, poorly documented modules. Nobody is sure of the full extent of its functionality, but the possibilities seem endless. Also known as Non-Deterministic.

3.2 Commando

The Commando Pattern is used to get in and out quick, and get the job done. This pattern can break any encapsulation to accomplish its mission. It takes no prisoners.

3.3 Intersperser

The Intersperser Pattern scatters pieces of functionality throughout a system, making a function impossible to test, modify, or understand.

3.4 Instigator
The Instigator Pattern is seemingly benign, but wreaks havoc on other parts of the software system.

3.5 Momentum

The Momentum Pattern grows exponentially, increasing size, memory requirements, complexity, and  processing time.

3.6 Medicator
The Medicator Pattern is a real time hog that makes the rest of the system appear to be medicated with strong sedatives.

3.7 Absolver

The Absolver Pattern is evident in problem ridden code developed by former employees. So many historical problems have been traced to this software that current employees can absolve their software of blame by claiming that the absolver is responsible for any problem reported. Also known as It's-not-in-my-code.

3.8 Stake

The Stake Pattern is evident in problem ridden software written by designers who have since chosen the management ladder. Although fraught with problems, the manager's stake in this software is too high to allow anyone to rewrite it, as it represents the pinnacle of the manager's technical achievement.

3.9 Eulogy

The Eulogy Pattern is eventually used on all projects employing the other 22 Resign Patterns. Also known as Post Mortem.

3.10 Tempest Method

The Tempest Method is used in the last few days before software delivery. The Tempest Method is characterized by lack of comments, and introduction of several Detonator Patterns.

3.11 Visitor From Hell

The Visitor From Hell Pattern is coincident with the absence of run time bounds checking on arrays. Inevitably, at least one control loop per system will have a Visitor From Hell Pattern that will overwrite critical data.

References

Gamma, E., Helm, R., Johnson, R., Vlissides, J., Design Patterns -

Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995.

Michael Duell is an Engineer at AG Communication Systems, where his

Resign Patterns have been rejected in favor of the Gang

of Four Design Patterns.

"Resign Patterns: Ailments of Unsuitable Project-Disoriented Software,"

The Software Practitioner, Vol. 7, No. 3, May-June 1997, p. 14.

Epic Q&A submission

Jira submission from a Quality and Assurance department :

JPEG screenshot inside Internet Explorer showing a screenshot of MSPaint editing a screenshot
of Firefox browser runnng the application.


Epic. 

Must go...deeper...

Source from reddit.

Netbeans 6.5 JDK Not Found

If you are trying to install an old Netbeans version under Windows 7 64bit ,(Netbeans 6.5), you may encounter the following error message:

Java JDK Not Found

This is a known issue and filed as a bug under Netbeans' tracker but there is a solution.


The workaround is to manually extract the exe and execute the bundle.jar installer.
From the commnand prompt execute the following two commands:

netbeans-6.5.1-windows.exe –extract

java -jar bundle.jar

The first one extracts the installer from the exe while the other executes the installer.

Happy 20th anniversary, Linux

How software companies die

An essay by Orson Scott Card, found it lurking in my articles folder but i lack the source.
A very true and entertaining read. Hope you enjoy it.

---

The environment that nutures creative programmers kills management and marketing types - and vice versa. Programming is the Great Game. It consumes you, body and soul. When you're caught up in it, nothing else matters. When you emerge into daylight, you might well discover that you're a hundred pounds overweight, your underwear is older than the average first grader, and judging from the number of pizza boxes lying around, it must be spring already. But you don't care, because your program runs, and the code is fast and clever and tight. You won. You're aware that some people think you're a nerd. So what? They're not players. They've never jousted with Windows or gone hand to hand with DOS. To them C++ is a decent grade, almost a B - not a language. They barely exist. Like soldiers or artists, you don't care about the opinions of civilians. You're building something intricate and fine. They'll never understand it.

BEEKEEPING

Here's the secret that every successful software company is based on: You can domesticate programmers the way beekeepers tame bees. You can't exactly communicate with them, but you can get them to swarm in one place and when they're not looking, you can carry off the honey. You keep these bees from stinging by paying them money. More money than they know what to do with. But that's less than you might think. You see, all these programmers keep hearing their parents' voices in their heads saying "When are you going to join the real world?" All you have to pay them is enough money that they can answer (also in their heads) "Geez, Dad, I'm making more than you." On average, this is cheap. And you get them to stay in the hive by giving them other coders to swarm with. The only person whose praise matters is another programmer. Less-talented programmers will idolize them; evenly matched ones will challenge and goad one another; and if you want to get a good swarm, you make sure that you have at least one certified genius coder that they can all look up to, even if he glances at other people's code only long enough to sneer at it. He's a Player, thinks the junior programmer. He looked at my code. That is enough. If a software company provides such a hive, the coders will give up sleep, love, health, and clean laundry, while the company keeps the bulk of the money.

OUT OF CONTROL

Here's the problem that ends up killing company after company. All successful software companies had, as their dominant personality, a leader who nurtured programmers. But no company can keep such a leader forever. Either he cashes out, or he brings in management types who end up driving him out, or he changes and becomes a management type himself. One way or another, marketers get control. But...control of what? Instead of finding assembly lines of productive workers, they quickly discover that their product is produced by utterly unpredictable, uncooperative, disobedient, and worst of all, unattractive people who resist all attempts at management. Put them on a time clock, dress them in suits, and they become sullen and start sabotaging the product. Worst of all, you can sense that they are making fun of you with every word they say.

SMOKED OUT

The shock is greater for the coder, though. He suddenly finds that alien creatures control his life. Meetings, Schedules, Reports. And now someone demands that he PLAN all his programming and then stick to the plan, never improving, never tweaking, and never, never touching some other team's code. The lousy young programmer who once worshiped him is now his tyrannical boss, a position he got because he played golf with some sphincter in a suit. The hive has been ruined. The best coders leave. And the marketers, comfortable now because they're surrounded by power neckties and they have things under control, are baffled that each new iteration of their software loses market share as the code bloats and the bugs proliferate. Got to get some better packaging. Yeah, that's it.

Current state of Jenkins presentation

Current state of Jenkins

View more presentations from Kohsuke Kawaguchi 

Code Fitness - Visualize your java classes and identify complexity

Before refactoring a class, package or library  weak spots have to be identified. There are many code analysis tools providing insight, hints and alerts as to where someone should focus.

But before reading these metrics i'd prefer to have a quick look, an overview of the structure and the complexity underneath especially in a new project. Something visual would be ideal.

So jSizer comes to the rescue. It is a small swing-based app which reads a jar file and produces a graph depicting
packages' - classes' node hierarchy while effective coloring and shaping  helps to differentiate each node based on some vital metrics.

Some examples:

To interpret the graphs :

• The Width of a class-node represents the number of fields.
• The Height of a node represents the number of methods.
• The Color represents LOC - lines of code.

So, quoting jSizer's author Robert Olofsson:

What you want to do is to look at the graph, find the big dark boxes and possibly refactor them.