less agile?

It's a stripped down version of Scrum what we are doing. I mean, not that we wanted to change anything, but we had to adapt.

Cause we did not have a tester from the beginning of the project. So we tested more.

Cause we don't have stand-up meetings. But our desks are practically touching each other, so everyone knows what the others are working at, all the time. I know, you can't afford this luxury, but we are just a team of three. Blockages ... send an email and wait, be inventive, find something else to work at.

Cause we don't have a one-sprint long backlog. But we are continuously eliciting requirements from the over-the-ocean project manager, team leader and GUI specialist. They know what features the clients want. That's where the final say on GUI usability and consistency is ... still we are continuously pushing to have a sprint backlog.

I'll tell you what's better than a traditional stand-up meeting. It's our weekly sync where we started  yesterday to use a virtual room to demo our progress. That's my favorite side of Scrum, the demos. Those at the end of the sprint. But now we are doing them weekly, I think this keeps the momentum.

I know, it might not be Scrum, but we are agile, in our own special way.

paradox (II)

The original paradox urged me to look for some answers. I've been thinking but mostly I've been asking around. I am not alone in this as a few others in other software companies could tell the same kind of stories.

The most mentioned reason is boredom. Developers' boredom. Laziness. Not incompetence. Which is sad. You can do a thing right, still the day is too alike the others, so you do a poor job just to finish earlier, or cause you've done it so many times before.

The original post title was Don't hire contractors ... It doesn't say it all, but it's catchy and with a reason. It turns out that in case of my project a major cause of poor code was the work of contractors. Not that they were incompetent, not they were even bored (cause those were the times in the lifecycle of this project when no one could get bored), it was the market forces that made them write code fast, not test and ship early. But they grew and got market share. (See here a post that says they might have even chosen the right path from a business point of view). They provided a job for me, the one who swears at their code.

No automated tests, no code reviews, no time for a best-practices catalog, an outdated wiki. Great programmers. This is the recipe for a best selling product !?

Anyway, back to the original title: if you can afford to ignore the business and only care about code, don't hire contractors if you don't have a good development process to oppose some forces to their fury of producing lots and lots of code. Contractors come and go, so they have to produce code to justify their cost (Permanent employees have to do that too, but they are not under the same time stress. They are hired forever, or until a bad review following the last bad review comes, which might take two years in some companies).

Build contractors a light but working development process, allow them to be creative, but don't let them fool around with code, nor leave garbage behind. Or else a developer like me in a post-contractor era will complain that the code is poor and lose time solving paradoxes instead of producing code ... top-quality code.

agile architecting

The whole IT world "is" / claims to be / wants to be agile today, which reminds me of the days when the hype was about multimedia ... every CD out on the market was multimedia.

But actually this title has quite some substance if you watch this presentation The evolving Guardian.co.uk architecture. A presentation worth watching from which I would extract these ideas:

• architects, don't underestimate developers when tech issues must be solved !
  
• having a parallel platform team to deal with non-business, purely technical stuff
• new architecture optimizations and improvements being much later needed than estimated
  

paradox

It's a bunch of smart people, I hear them all the time in meetings and I read their emails ... How can I say they are smart ... a good percentage of what they say I don't understand! They are the core that built and are now extending and selling a well known HP product. And they are polite and helping, which is another sign that they are smart ... I mean they must be smart, I feel it.

How come their frameworks are over-engineered, the code is full of dirt, the test coverage is close to zero? And something along this paradox to be tagged as sad: how come they are forgiving with this state of facts?

the young and the motivated

Its probably the young IT industry in Romania that makes recruiters add this sort of benefit in most of their emails and ads: You will be part of a young and motivated team.

I am looking forward for the times when I'll read this instead: You will be part of a very experienced team with great past achievements.

intuitive [/] emacs

... a screenshot of mcedit, no comment

new comers are right

They see the code base differently, they are unbiased: they don't know who owns a package, they don't know there are historical reasons why the code is so bad, they don't know the past trade-offs and political games, they are unaware of the dirty workarounds that still keep things moving.

You've been "contaminated" all this time you've spent in the project. You know package A is owned by the team lead so you won't review it harshly, you naturally justify the bad dependencies with the schedule pressure two releases ago, you got used to unsetting this environment variable and creating that magic file by hand each time you run a deployment and those worthless TODOs seem a natural code outfit, they almost please your eye.

New comers can't see the forest for the tree, but this makes them focus on every tree. And sometimes healing tree by tree is what gets a global healing effort started. What they see is the current technical debt at a granular level. They are not yet bored with the codebase so they are eager to find the problems you have long accepted.

Only if there was someone to weight their opinions against the contaminated ones ... and do it faster than the team contamination velocity.

my wider resume

... you're looking at it.

It's the entire collection of material I've been posting here. It's not mere writing, it shows a way of thinking (consistent?) that a standard resume won't show. Anyone working with me or who I am working for can expect I'd want to implement the ideas outlined here during the partnership, so they'll be well informed when choosing if they want such a partnership. It's a solid step to openness.

It's my contributions to software in general: code snippets, reviews, technical HOWTO-s, quality assurance, coding for fun and contribution to OSS, and they are all linked to from here, each with its own story.

And it's fueled by contributing. There are still many other ways of contributing that I can think of: writing a full blown article for an IT magazine, registering as a speaker to a software conference, giving a speech at your local university, creating and maintaining a product or website.

Is this worth the effort? Probably not if it's an effort and there is no fun in it. But if it _is_ fun, then this is a step forward for you who want to play in a higher league.

You could be invited to join a company and not apply to join one, you could have a discussion partner and not an interviewer in front of you, it could be a dialog like We heard about you and appreciate your work versus an interview like Please tell us about yourself and your last 5 professional years; then it would continue with We are perfectly aware that someone with your capabilities can help us ... compared with We'll continue with a short list of 10 questions.

Now, tell me, is it worth the effort?

the tired programmer

Are you? A programmer ... I mean tired? Aaa ... both? Well ... are you chronically tired?

Of what? Innovation, progress, change, every-day learning, designing for change ... CHANGE !!! brand new everything, industry immaturity, the multitude of unsolved problems, technology stacks that resemble a sky-scraper, embracing CHAAAAAAANGEEE ... ?

What if this were true? Well, got you thinking ...?

javac from the command line

You are a Java developer and your platform of choice is Windows. I'll point you to a deeply nested directory with lots of source files in it and ask you to compile them. How do you do it?

If you immediately fire up your IDE, create a project, set it up with the source files and output directory and hit the Make button, then find out there is a quicker way to do it from the command line, an option many ignore:

cd the_directory_i_gave_you
dir /b /s *.java > source_files.txt
mkdir ..\out
javac -d ..\out @source_files.txt

one-option names

Is the name of a software shop important in making the business successful? I'd say no considering that many stupid-name companies do great. Back in my iQuest days, we used to work together with a UK software consultancy company called Conchango, how about that for a name?

Still I can't help wondering about companies whose names relate to current technologies and trends - what about the times when these will be obsolete? If you are thinking ObjectMentor, I think they'll survive, and it turned out it was a good name choice since object has become the synonym for good programming style.

But what about XML-INTL? These guys should have it in their mission to make sure XML never goes away ... it can't be that hard, we all love XML, don't we? XML Networks are clearly better positioned, networks will not go away soon, if ever.

A particular case are the names in the Microsoft world. The chances a technology will go obsolete are weaker in this self-contained corner of the world where the open source community who usually create novelty (thus obsolescence) is not so active.

One trend I find today is promoting the website and not the company name. Clearly a better strategy from this point of view: in rough times, just clone the website and advertise for another technology while still operating the same company.

So from a technological name point of view, the business success recipe is clear: the broader the meaning, the less chances to go out of business.

pmd applied or the chain of good things

Because the 'patching period' is close to finish and I have zero bugs in my queue now, I put some time into investigating tools that would reduce my frustration with the code, so I devoted the start of the week to PMD.

There are quite a few angles you can approach software quality from and PMD does this by analyzing the source code for mistakes and even ventures into reporting bad code design. By going after source code quality, you leverage the fact that there is greater consensus about whether code A is better than code B than if you were to decide on more general quality metrics like maintainability: how confident would you be in asserting that project A is more maintainable than project B?

It took me about one day to go over over the set of PMD rules applicable to my java desktop project; some of them I had to try out and I eventually filtered out those that I found controversial, reporting false positives and those that simply didn't feel right. I wish the project maintainers could exercise their veto more often against the rules submitted by various contributors, but I guess the philosophy is to let you use just the rules you like.

The way you can do that is create your custom rules file which will include only the PMD rules you want run - notice some of them can be customized with properties -

<ruleset name="My rules"
    xmlns="http://pmd.sf.net/ruleset/1.0.0"
    xsi="http://www.w3.org/2001/XMLSchema-instance"
    schemalocation="http://pmd.sf.net/ruleset/1.0.0 http://pmd.sf.net/ruleset_xml_schema.xsd"
    nonamespaceschemalocation="http://pmd.sf.net/ruleset_xml_schema.xsd">
  <description>A custom rule set</description>

  <rule ref="rulesets/basic.xml/EmptyCatchBlock">
    <properties>
      <property name="allowCommentedBlocks">
        <value>true</value>
      </property>
    </properties>
  <rule ref="rulesets/unusedcode.xml/UnusedPrivateField">
</ruleset>

and include it in the PMD classpath.

Two benefits I am expecting from PMD: a smaller code-base (rules like UselessOverridingMethod and UnusedPrivateMethod) and a slightly better/faster usage of the Java library classes (rules like StringInstantiation and InefficientStringBuffering). A collateral benefit could be that my team would learn to write better code after they'll correct their mistakes. What if they will be so thrilled with the experience that they will at their turn plug in new quality tools ... what if they will blog about this and spread the word to a wider audience? ... I can only imagine ...

In the end I'll just say that an improvement never comes alone: here is my humble shot at improving PMD itself:

your career

This read is an interesting way to start your morning ... made me think.

If you stopped doing it at a certain moment, or had never done it, start (re)investing in your career. Investing needs efficiency, and efficiency brings time into equation. Your time is limited, so be picky about what you keep in your list of blogs. Focusing on ticking as many New blog read boxes as possible is not a metric to base your career development on.

So stick to good blogs.

defensive programming

Defensive programming complements patch programming. It is a must for those who want to enjoy life outside of programming and not climb the programmer ladder.

Below I'll unfold a short initiation session, so read on when ready ...

Let's start with the basics, I'll give you your motto: An extra safety net can't hurt. It's the salute that a defensive programmer uses to greet other defensive programmers. At the time of this writing, it is not known that defensive programmers have a special dress code, so you'll need to learn the salute by heart, and as a safety net, keep a paper with some sample code of yours at all times with you. This way you can easily prove your membership to the group and you won't be taken as an undesirable TDD- or refactoring-programmer.

A good practitioner of defensive programming requires that you:

1. Extensively use safety nets like if (obj != null) sometimes right after the object is created, so you'll never be responsible for a NPE again.

2. Add extensive comments explaining why you did what you did in the way you did instead of refactoring the code. This way, if somebody does not understand your code, it's completely their fault.

3. Clone an object both when you set it in its container and when you return the object back from the container; this way you'll be extremely sure that nobody will modify the initial object.

4. When creating a class with similar functionality to an existing one, copy and paste the old class; better yet, even if your class will deprecate / replace the old class, leave it there in case someone takes pleasure in investigating obsolete code.

5. When extending a class, to make sure that an inherited method is called, override it and merely call the super version; who knows what happens with the dynamic dispatch mechanism in the JVM and your method won't be called.

Far from being exhaustive, this list should have given you a good picture of this programming style. As a final advice, take some rhetoric classes: they will teach you how to convince the rest of the team that those bugs in your list ... aren't actually yours.

patch programming

It is again that time of the year when we work like crazy to clear the list of bugs; it is right after we developers did our part of feature regression testing, and right before the product will enter the QA phase, and then product launch.

It is that time of the year when we won't make important changes to the codebase not to break existing functionality. That time of the year when I am answered back with "I suggest you keep that in mind for the next version and just put a workaround instead".

That period when good old refactoring is not practiced much, and instead we code-patch. Some of the patches will be checked in with TODOs, but some of them will lack even this. Because I expect the number of TODOs in the code to increase, I decided I would put a "baseline" on the number of TODOs and compare them with the new number after release. So here it is, 895 TODOs and 31 FIXMEs. I am thinking now at a possible new code quality metric TODOs/codebase size.

If you are the optimistic type, you will have your hopes that after product launch, we will definitely replace the hacks with proper code. And I just have my doubts because everybody will be coding new features in that time of the year.

The result of all this development process can't be other than increasingly dirtier code. But how much can the code become dirtier before "exploding"? And what will this explosion mean? From a technical perspective it can mean writing the same amount of code in more time, or hiring more developers, or less frequent releases, or less features in new product versions. The peak could be a rewrite. All of these have economical consequences that you can easily infer.

I gave all of this some thought and the solution I see is practicing Zero Known Bugs. ZKB means a much shorter period like this one, so less opportunities to introduce hacks. ZKB on anybody's buglist means more confidence that making a change won't break existing functionality, means more focus on activities with added-value like new features. Zero-bugs means a smaller QA team, less fiddling with the bug tracker and less time from managers that weekly count bugs and take time sending encouraging emails that say We can do it together. It also means more free weekends and less stress.

So why not do it? I guess my next step is how I can convince the one who make decisions that this is the way to go.

P.S. After I wrote this, I intended to find a good link about ZKB. You should read it. So yes, it is controversial like most of the software development topics. But be it exactly zero, or 2, the principle is valid and we as a team are far from it, so I still needed to write this piece as one who had never been in a team that practiced ZKB :(

boring (III) / unread email count

After the fun I had last time with JavaScript, I felt like coding another micro-project along the same idea: this time I wanted to display the unread emails count in the Reader page.

So I needed that special URL GMail uses to retrieve the count. So I sent myself several emails and all this time I used HttpFox to sniff everything that went in and out my browser; in the end I discovered a JavaScript object that held the information I was after.

Next, I needed to make an async request to the URL I found previously. A very forgiving version of XmlHttpRequest that allows one to make cross-site requests is the one GreaseMonkey provides.

Next, good old string parsing did the job of extracting the unread count from the response I got from GMail, so finally I just needed to append the count to the existing GMail link in Reader.

At this step unfortunately, more testing proved that the URL I've found worked for me only and not for other GMail accounts. I relied on the fact that account specific information would be sent using cookies, and I failed.

So I was back at finding the magic URL. My search went on through cookies, text/html and text/javascript content GMail responded with and I was lucky enough to track down the same js object sent back from another URL, this time a simple one with no scrambled GET parameters. A quick test for 3 GMail accounts on 2 different machines proved it working.

You can install the script from here.

boring (II)

If the advice in the first part of this series did not work for you, or the book you picked is too long and you'd happily put it aside for a period, here is a new idea: code your own micro-project.

It should take you ~20 minutes per day, because what I am talking here is swapping your daily blog reading with coding. And it should be smart so that you don't get bored with your own chosen assignment.

It could require much thinking, as it's the case with an algorithm from commons you've been using and you are thinking to rewrite it and make it faster. It could require studying as it's the case with a new programming language in which you want to write a Hello World. It could require browsing the web in search of information as it's the case of a public web service with which you want to interact.

And here is my story: I've been using Google products for quite a while, indeed Reader is my first browser tab; and you've realized by now that I'm also a user of Blogger. Opening Blogger always required opening a new tab and typing the blogger URL, then hitting Enter :). Yes, it's a matter of seconds, but don't forget I needed an excuse to start my micro-project.

So I ventured into the realms of Greasemonkey and with this, into Javascript and DOM. I haven't been coding hard-core javascript since the days of Netscape 4.7, and here was my chance to code JS again. I heroically resisted the temptations jQuery laid in my path ... no, this time I'm not gonna let you help me, this time I want my hands dirty with JS.

Long story short, here is now the top of my Reader page, I am just one click away from you (would you be so kind to notice the link to Blogger that my script adds whenever I access a google page):

a good way of complaining

Do you love the things you do? ... then criticize, suggest improvements, and post bugs.


Stop complaining about the tools you use if you haven't done a thing to make them better.


Because you are part of a team, it is not only about the things you fix, but also about the things you bring to others' attention.

you at work

How would you picture yourself during your 8h-work a day? If you were to draw yourself in a typical work day how would you do it?

Forget about your current work place, just imagine, draw your mental projection of you working. Would you be at a desk, would you wear glasses, would you have plants around you, would it be artificial light, would it be air conditioning?

How do you think the others around you (would) envision you - the professional programmer - in a typical work day? Would it be in a dark corner, bent over a keyboard and wearing your nerdy expression? Or it'd be under sun light, a merry, open expression on your face?

If it is a gray environment what you picture, if it's tens of light bulbs above you, if it's only aluminum and concrete and no plants, if it's halls and no terrace, then there is an alternative and architect Norman Foster knows it.

Watch and do the exercise above again. (The first 10 minutes of the video might bore the impatient, but it becomes really interesting afterwards)

the future is bright

This might sound familiar to you, but since the marketing department think this is important, I might as well spread the word. These are excerpts from an email arrived this morning in my Inbox:

[...] the most successful leaders will be those who leverage technology and change to go beyond new mandates for efficiency

Nearly three-quarters of CIOs now believe that long-term strategic thinking and planning is the leadership competency most critical to their roles

Clear words, clear guidelines, now we have the recipe for defeating the world economic crisis.