When Architecture and Maintenance Meet

In his excellent blog, Jeroen van den Bos is running an insightful series of posts under the Software Maintenance category.

The fact that he so clearly identifies software architecture as a critical factor in its maintenance came for me as revelatory of what is the Ariane's thread that guides my professional career (despite passion, of course). Being an Industrial Maintenance Engineer by training, a Software Developer by passion and a Software Architect by experience, it is clear how these drivers get weaved together into the very fabric of my craftsmanship. In fact, back in 1992, the theme of my graduation project was Software Maintenance. Was all this predetermined?

As critical as it is, software architecture is still an emerging profession in the IT field. After the supremacy of the project managers, architects start to have a saying in the equation. Often, the resistance comes from developers who consider architects as only good with drawing boxes and arrows. This usually lasts until they have to work on a poorly architectured system...

Software architecture is necessary for building systems that:

• are fun to build, as no-one enjoys fighting with an ill-conceived application, whether its internal design or external interfaces are flawed,
• last, in the sense they are versatile enough to evolve without breaking and within reasonable budget,
• and are maintainable, mainly because they are thoroughly testable and written following well defined conventions and standards.
  

In fact, even the Matrix could not do it without such a profile on-board. Is this a model to follow? Maybe, if we can cut the undecipherable mambo-jumbo speech.

Agile Hiring?

At my workplace, I see new faces every week as the company is still aggressively hiring. Having a very bad (or selective?) memory, this is a terrifying challenge for me: will I ever recognize anyone? Thanks to the internal wiki-based directory with mugshots of all the happy employees, I can at least learn at my pace the monikers I need to know.

This constant workforce growth sent me back, again, to my reflections on how to pick up the right candidate. Not anyone can use robots to do this, so can a rule of thumb be of any help?

Initially, I thought that selecting the ones who get things done would be enough.

But there are so many awkward ways to do things that (seem to) work that this I came to consider this rule as too simplistic and decided to enrich it this way: get the ones who get things done right.

But then, the issue is that the right way of doing things must be defined and specified, which implies a lot of preparatory work and the risk of erring in the toxic realm of micromanagement.

So I finally decided that the best way of selecting people is to keep the ones who actually remove work from you rather than add extra work on your shoulders. This implies that the candidate must actually be hired and exposed to the reality of work in the company. This is why orientation periods exist.

This might sound like a waste but I prefer to consider this as an agile way of dealing with new hires: select them with the information you have at recruitment time then let time pass and re-adjust to reality.

Copy Pang

When I read the article "Three Public Enemies: Cut, Copy, and Paste" published by Zoltán Adám Mann in the July 2006 issue of Computer, I first wondered how this topic could be of any interest to me. I decided to read it anyway, mostly because the abstract caught my attention:

"Copy-paste might seem to make life easier, but it often leads to inconsistencies. Giving users the freedom to specify semantic relationships among copied objects can help rectify this crime."

Of course, reading the article proved, again, that any prejudice-driven judgment is flawed: there is something really broken with copying and pasting (despite turning lazy developers into dirty ones: Functions? What for? I can copy/paste!).

I have experienced today what I consider the worst unexpected side effect of using this facility I have ever met so far. And it was pretty embarrassing. Read on.

I checked out of SVN a workmate's project I wanted to copy two files from into my Eclipse workspace. In fact, I was interested in these files and the particular folder hierarchy they are stored into (Maven site and APT files, for the curious). So I copied the interesting folder from this project and pasted it into my project, totally unaware of the fact that I was also copying and pasting the hidden SVN control files.

Of course when I wanted to check this back into my project, I was actually checking back into his project, while getting tons of undecipherable SVN insults in the console. Did not I say it was embarrassing? Man, what a shame.

So the lesson for GUI designers is the following: If you implement a feature that performs an operation of any kind but which ends up with a visual feedback, you should not do more than what is actually visible. Or at the very least warn the user that invisible operations will happen.

In my case, the visible feedback from the folder copy and paste operation was the addition of icons in the hierarchy representing my Java project. I should have been warned that other non-visible resources where also involved into the operation.

Well, I might not have read the warning dialog but then, that would have fully been my fault!

The Power of Openness

I was about to rant on the fact that, though "BEA is proud to provide complete online documentation for all BEA products", their site does not offer any search feature.

Then, duh! It stroke me that they do not need to provide such a feature. They only need to make their content accessible and well organized so that Internet search engines can do their job and voila! Anyone can search through their content using his or her favorite engine.

This sounds incredibly obvious but it is not. Many vendors still hide their documentation in password protected sections of their site, preventing robots to crawl and index them. This usually translates for us, users, into trying to get results from home made search engines that are case sensitive, do not support any typo and are, in general, reluctant to find anything useful (they are probably built after a famous canine model).

In a broader sense, the promises of the Internet will materialize when we will all expose our public data in an organized, unified and standardized way. Then the time of so-called social networks will be over: we will be using search and data extraction tools to build views of the Internet that are relevant to our purpose.

Does not this sound like semantic web? Is there a human friendly alternative?

UPDATE: It might well be social networks open APIs?

Geek Is Good For Life

There is a great post in Rands In Repose talking about the importance of staying flexible and not stopping to develop.

With much talent, this post echoes with my two years old ramble about dumb standard IT career paths, which start rooted in technicality but then strongly orient people away from it. How stupid is it to pull software developers out of the heart of the battle as soon as they have reach a great level of performance and expertise in order to turn them into frustrated managers?

The system is actually much subtler than that: software developers are teased into pulling themselves out through HR designed career paths that incarnate in artificial titles and levels and progress steps leading nowhere close to professional satisfaction.

Will technicality be assumed one day as a subject of pride? Should I keep wearing ThinkGeek t-shirts as a protest until this day happens?

Cosmos Is Next-door

This is an amazing picture I can only feel but like sharing. Read the complete and amazing story on APOD.

Art? I Choke!

After wading in a massive plate of spaghetti code that decency, more than professionalism, prevents me to disclose its origin, I came to the conclusion that I should never ever suggest that software development can be compared to an art. Never. Ever.

This opens the door to bad artists, the ones who do not care at all about the fact they are not alone on earth. No, in fact they do care about others but only when they will decide to expose their creation in the open ; and should the rest of the world dislike their masterpiece, these bad artists will turn depressed and start all over again. Alone. In isolation. Disregardful of the rest of the world.

And that is my point: as a software developer, we can not ignore the rest of the world and this at no point of our work. Not even before we think we can start showing something. And this is why:

• There is no pride nor satisfaction in re-inventing the wheel. If you do like it, please get another job. Right from the very beginning of a project and constantly during the course of it should a software developer be aware (or at least do his bets to gain awareness) of what is going on elsewhere. Starting from the principle that there are many people that outsmart us out there (at least, there are many smarter than me) and that a piece of code that has been used and re-used and abused for a while is stronger than anything that could come out of our brain, we must do our best to figure out if something that does what we want has not already been written and published. Some call this prior art and this is the kind of art I can live with.
  
  
• There is no pride nor satisfaction in clever coding. Come on, school is over, no need to hide from your neighbour. Code should go in the open, not necessarily outside of the company's network, of course, but it should be visible right from the beginning in whatever repository is in use. And it should be readable, understandable ; written like if it does matter that other people on earth can read it and still enjoy the rest of their day. After-hours code obfuscation is a modern form art and this is certainly another kind of art I can live with.
  

Not following these advices might spoil the lives of these others that surround us, something a genuine bad artist will not care about. But would he care if his masterpieces end up exposed in the Daily WTF?