Accessing the current Subversion Revision Number in Gradle

A common use case for build tools like Ant, Maven or Gradle is to retrieve the current revision number of the project sources in the Version Control System (VCS), in many cases Subversion (SVN). This revision number is then used in the file names of the build artifacts, for example. As mature build tools, Ant and Maven provide plugins to access the current revision number of the SVN working copy. But how about Gradle?

Having recently moved from Ant to Gradle in ~500.000 LOC Java project, I can say that Gradle offers a lot of well-thought-out features that make life easier. However, getting the Subversion revision number of a project workspace is not one of them. It’s remarkably easy to do it yourself, though, as shown in the code snippet below.

Using the buildscript closure you can define dependencies that are only available in your build script (i.e. these dependencies do not spill into the dependencies of your project). Using this way, you can add the dependency to tmatesoft’s SVNKit to your build. SVNKit provides a Java API to Subversion funcionality.

By defining a function (named getSvnRevision() in the snippet above), you can then simply use SVNKit to retrieve the current SVN revision number from your working copy. This function can then be called anywhere in your Gradle build script. In the case of the snippet above, I used it to append the revision number to a standard major/minor/bugfix versioning pattern. This complete version number can then be used in Gradle subprojects.


Programming a State Machine in Java

Some programming problems center around managing different states and the transitions between the states. These problems are ideally suited to be solved by using a finite state machine. This post shows a way of programming a finite state machine in Java to solve a text parsing problem and to keep the readability of the code at a maximum at the same time.

The Problem: a Parser for Unified Diffs

Recently, I needed to parse a unified diff. I looked for a Java library that does this for me without luck, so I decided to roll my own since it is not that big of a problem. A unified diff is a text fragment that contains the differences in lines between two text files (or between two versions of the same text file). It looks something like this:

[gist file=unified-diff.txt]7512852[/gist]

This text is to be parsed to create a Java object that contains all information.

A State Machine to the Rescue

Luckily, a unified diff follows a pattern that can be parsed. There are only a couple of different line types, each line type containing some specific information. These are the possible line types:

  • HEADER: a header line that contains part of the header of the diff
  • FROM_FILE: a line that contains the name of the first file that is compared
  • TO_FILE: a line that contains the name of the second file that is compared
  • HUNK_START: a line that marks the start of a “hunk” of differences in both files, providing the line numbers of the start line and the end line of the hunk
  • NEUTRAL_LINE: a line within a hunk that is contained in both files
  • FROM_LINE: a line within a hunk that is contained in the “from file” only
  • TO_LINE: a line within a hunk that is contained in the “to file” only

Projecting these types to the diff example from above looks like this:

[gist file=states.txt]7512852[/gist]

Now, each line type can only be followed by a certain set of other line types. Modelling the line types as states we get a state machine like this:


Coding the States

So, what’s the best way to code such a state machine in Java? Te natural feature for representing states in Java code is an enum. The plain enum would look like this:


Note that there are two additional states for the initial state and the end state.

Coding the Transitions

That was easy. The question how best to code the transitions between the states is a little harder. One way to do it is to simply let each enum constant implement a method called “nextState” that returns the next state depending on some context information.


Here, each enum constant has to implement the abstract method nextState that takes an object containing some context information about the line of the diff that is currently being parsed and returns another enum constant representing the next state. Usually an implementation of the nextState method should not be overly complex since it simply uses a couple if/else statements to return the next state based on the current state and the information in the context object (an object of type ParseWindow in this case).

If calculating the next state becomes more complex, you should code each transition in it’s own class and simply call that class from the nextState method.

Coding the “Engine”

Having coded the states and the transitions between those states, you need some kind of “engine” that drives the state machine from the initial state through a number of other states to the final end state. While the structure of the state enum is pretty generic, the engine is very specific to the problem you are trying to solve. In the case of a text parser the engine starts by calling the INITIAL state’s nextState method providing the first line of the file and some context information on the next couple lines. Since the first line must be a HEADER line, this will be the result.

Now that we know that the current line is a HEADER line, we know how to parse it. Having parsed the first line, the engine takes the second line and passes it along with some context information to the HEADER state’s nextState method. Lather, rinse, repeat until the END state has been reached.


State machines are a natural way to solve some programming problems, parsing problems probably being the most prominent among them. However, a state machine like this can also be a nice and readable way to solve business problems like the transitions between states of an insurance contract or states of a user going through a complex registration process.

A Live Example

The code examples above are excerpts of a live github project called diffparser. Feel free to have a look at the source.

Why and How to Migrate from Eclipse to IntelliJ IDEA

After years of programming Java with Eclipse, and multiple hints from other developers that IntelliJ IDEA is superior to Eclipse, I finally tried it out. Meanwhile, I’ve come to the conclusion that programming with IntelliJ is just so much more fun than with Eclipse. Here’s some Pros and Cons about IntelliJ compared to Eclipse and some tips on migrating from Eclipse to IntelliJ.


As I am writing this, I have been trying out Intellij for about 3 weeks after having used Eclipse for about 6 years. In those 3 weeks, I have come to love many small and big features of IntelliJ that Eclipse does not offer (at least not without searching for some plugin that does the job). Here’s the positive things I stumbled upon while trying out IntelliJ:


My current (legacy) project at work consists of about 50 modules, one Eclipse project each. The number of projects combined with Dependency resolution through the IvyDE plugin, it appears that I am spending more time waiting that coding. After having migrated the project to IntelliJ, my workspace is much more responsive. Searching is blazingly fast. Everything just seems to work faster. IntelliJ is only doing the work it needs to do, instead of doing all the work in case that you might need the results in the future. Because of this, it also has a smaller memory footprint.

Flexible Project Structure

In Eclipse it has always been awkward to create projects with a nested directory structure. It works when first checking out the main directory from VCS as an Eclipse project and then importing all projects that are contained within the main directory. Then you have the code of all Eclipse projects twice in your workspace, though: once in the Eclipse project of the main directory and once in the actual Eclipse project… . The project structure in IntelliJ is completely up to you. You import a directory structure and define which sub directories your modules are in.

Smart Tooling

IntelliJ comes with many features helping you to navigate or refactor code. There’s a shortcut for selecting the current word, then the current statement, the current block, and so forth if used repeatedly. Also there’s a shortcut for surrounding the currently selected code with try-catch, if-else, for-loop or several other code snippets. Using both those shortcuts together is an enormous help when coding, if you ask me. Auto-completion is also available everywhere, even when you don’t expect it. IntelliJ auto-completes my Maven dependencies in the pom.xml by checking which artifacts are available in my local repository!

Seamless VCS integration

The integration to Version Control Systems like Subversion or Git feels right at home in IntelliJ. No more switching to the “SVN Synchronizing” Perspective in Eclipse. Just click update or commit and go through the VCS dialog, which shows you all information you need. You can move changed files into different change sets which you can commit separately. And you can perform certain actions like code analysis or reformatting on commit (code analysis is enabled by default, which has saved me from a couple certain bugs already!).

Interactive Editor

The code editor is very interactive and marks up warnings and errors prominently. You can recognize outdated javadoc immediately, since @param-descriptions of parameters that don’t exist are colored red. If you use String.format(), IntelliJ tells you when the placeholders in your format string don’t match the parameter list! If you compile a regular expression using Pattern.compile(), IntelliJ will tell you if the regex is valid and even offers to enter test strings to match against it! IntelliJ also marks unused variables, methods and classes – not just private ones, but also public ones.

Intelligent Usage of Screen Space

There are no “perspectives” as in Eclipse. If you start a debugging session, the debugging view will simply open at the bottom of the screen. If you start a unit test, the testing view will open. No more switching between perspectives.

Cooler looks

IntelliJ ships with a pretty cool theme called “Darcula”, which is made up of dark backgrounds and light font colors and is a lot of fun to work with. There’s a theme plugin for Eclipse, but it only allows theming of the editor window.


Of course, IntelliJ has some drawbacks, too. I have expected more than I found, though. Here’s the list of bad things I found while evaluating IntelliJ:

Buggy Dialogs

When changing settings for project modules in the Project Structure dialog, the changes are not always saved as I would expect, resulting in having to do it twice. May have to do with the plugins, I’m using, though (I’m suspecting IvyDEA).

Awkward Renaming and Adding of Packages

When you want to add a new Package to an Eclipse-Project, you are presented with a dialog in which you can edit the fully qualified package name. In IntelliJ you only get a single input field for the last element of the name of the package to add or rename. If you want to add a package at some level in between, you have to add a package to the source folder and type the fully qualified name by hand.

Awkward Renaming of Modules

Modules have a directory name in the file system and a name within the workspace. Each time you want to rename a module, you are asked whether to change the former or the latter – I have not found an option to change both at the same time…very frustrating.

Configuring Subversion Integration can be awkward

If you are working with Subversion, you currently have to check out the sources initially via IntelliJ. If you check out the sources with another tool (like TortoiseSVN) and then import it into IntelliJ, it won’t work because of working copy inconsistencies!

It’s not free

IntelliJ costs money. A commercial single developer license costs €450. Which is a lot (at least, when trying to persuade your boss). Licenses for Open Source work are free, though.

Migration tips

Here’s a couple tips that might be helpful when you come from Eclipse and are trying out IntelliJ:

Use the default Eclipse shortcuts

If you have worked for years with Eclipse it seems to much for me to re-learn all key bindings. IntelliJ provides a default key binding that is based on default Eclipse shortcuts. Simply choose it from the list of available Keymaps in the Keymaps settings.

Disable “Caret after end of line”

Coming from Eclipse, IntelliJ has the annoying default setting to allow navigating a line after the end of the line. So, when you navigate up or down the editor to a line that is shorter than the line before, the cursor will stay at the same column instead of jumping to the last character in the new line, as I have come to expect. You can change this in the  IDE Settings by disabling the option “Allow placement of caret after end of line”.


Get acquainted with those shortcuts, they make working with code a breeze!

Show Javadoc on Mouse-Over

By default, IntelliJ doesn’t show the Javadoc of a class or method on mouse over. You can activate this by adding the following line to the file in the installation folder:

Add a Live Template for creating {@link}s in Javadoc

IntelliJ does support auto-completion of class names in Javadoc, but it doesn’t surround them with the {@link} annotation to create hyperlinks in the resulting Javadoc. To mitigate this, you can create a live template with the following text yourself:

{@link $LINK$}

Add a variable called LINK that expands to the expression “complete()” and give it the abbreviation “link” and set it to be only applicable in Javadoc. From then on, you can type “link” and then TAB to create a Javadoc link with auto-completion.

My Personal Conclusion

For myself, I have concluded to use IntelliJ from now on. It’s just so much more fun to work with! All I have to do is persuade my boss to spend some money on the licenses for my team and me… .

A brown-paper package.

How To Release Your Open Source Project to Maven Central

 Once you have created and fine-tuned your current programming project, you usually want to share it with all those developers out there who might have a need for your solution. For Java-based projects, Apache Maven provides a good distribution channel for this. With Maven, you can release your project to Maven Central, which is a global repository for open source Java projects that can also be accessed by build tools other than Maven itself. Since I have not found an easy-to-follow guide on how to do this in the web, I try to document the needed steps in this post.

Step #1: Sign Up at Sonatype

Sonatype is a company that provides all sorts of support and tools for “component lifecycle management” as they call it. Essential for us, they provide the access point to making a project available in the Maven Central Repository. You have to create an account at the following sites (for free, of course!):

Step #2: Create your project in JIRA

Log in to the JIRA system at with the username and password you chose in step 1 and create an issue of type “New Project”. Most input fields are self-explanatory. In any case, here’s what you have to put into those fields:

  • Project: select “Community Support – Open Source”
  • Issue Type: select “New Project”
  • Summary: name of your project
  • Description: to make things easier on the Sonatype guys, drop a line about what your project is about
  • Attachment: don’t add an attachment
  • Group Id: your desired Maven group id (your namespace). This must be a backwards URL like org.wickedsource (which is the namespace I use for my projects). If you’re not familiar with Maven, read this article on how to choose your Maven coordinates.
  • Project URL: URL to your project homepage. You should have a homepage for your project, even if it is just the frontpage of your github or googlecode repository.
  • SCM URL: URL to your source code management system like github or googlecode
  • Username: your JIRA user name
  • Already Synced to Central: choose “No”
  • Epic Link: leave empty

Some of the fields may probably be left empty and they will still create a repository for you, but it makes it easier if you provide all information. The Sonatype guys will usually respond within a couple hours, but it may take longer – be patient.

Step #3: Create a Key Pair

It is required for any artifacts you release to be signed. The easiest way to do this is by using GNU Privacy Guard (I use the Windows version of GPG). If you don’t have a key pair to be used in signatures yet, follow this article on how to generate a key pair and distributing your public key. You will have to choose a passphrase when generating a key pair. This passphrase will be needed later. If you have more than one key pair, make sure you define one of them as the default key pair in GPG.

Step #4: Create and Sign your Artifacts automatically with Maven

Once you have installed GPG and created a key pair you can use the following maven command to sign all your artifacts automatically:
Calling the javadoc and source plugins is necessary to create javadoc and source JAR files along with your actual JAR artifact. Providing javadoc and sources is a requirement for releasing open source projects to Maven Central. The gpg plugin takes care of signing all those JARs with your previously generated default GPG private key.

Caveat: the gpg Maven plugin has to be coaxed into actually signing your javadoc and source JAR files by adding the following configuration to your pom.xml:

[gist file=pom-plugins.xml]6653895[/gist]

Step #5: Deploy your Artifacts to your Staging Repository

If your request for a new Project in the Sonatype JIRA was successful, you will get an answer something like the following:

Configuration has been prepared, now you can:

please comment on this ticket when you promoted your first release, thanks

This basically means that they have provided a staging repository for you where you can upload your artifacts (automatically or manually). From this staging repository you can then manually trigger a release to Maven Central.

The important information is the URL to the staging repository. Add this URL to your pom.xml like this:
[gist file=pom-distributionManagement.xml]6653895[/gist]
Additionally, create a file called “settings.xml” with the following content:
[gist file=settings.xml]6653895[/gist]
Username and password should be the ones you chose when creating your account at Since the file settings.xml contains your credentials and thus sensitive data, it should only be kept locally and not be committed into any SCM system! The id (“sonatype” in the example above) is used by Maven to create the connection between your credentials and the repository id in your pom.xml.

Now you can call the following Maven command to create, sign and deploy your artifacts:
At some point during the build, you should see that your artifacts are being uploaded to the Sonatype server. The upload may take some while even if your artifacts are rather small, probably because the upload to the Sonatype server is throttled.

Step #6: Promote your Repository

After the Maven build has finished successfully, log in to and click the link “Staging Repositories” in the left-side navigation. In the opening tab, select your repository (you can use the “filter by profile” search box in the top right to find your group id). Click on the “close” button to close your repository. This triggers some validation checks on the files you uploaded. You can see if those validations were successful by clicking on the “Activity”-tab in the bottom part of the screen and selecting the “close” node. If there were any errors, fix the errors and deploy again. A documentation of the validations that will be performed when closing a repository can be found here.

Once all validations were successful, you can now promote the repository by clicking the “release” button. This means that you want the contents you uploaded into this repository to be released to Maven Central. After this has been done you should receive an email with the subject “Nexus: Promotion completed” and you should add a comment to the JIRA issue you created and wait for them to activate the sync to Maven Central. This may again take one or two working days. After this, your project has been successfully released to Maven Central and you can upload and then release repositories at any time without having to wait so long (repositories that have been successfully promoted once before will automatically be synced to Maven Central about every two hours from now on).

To check if your project is finally available at Maven Central, you can simply go to and search for your group id.

Caveat: I have noticed that sometimes the signature validation failed when I closed a repository on the Sonatype Nexus Server. After repeating the Maven deploy command from step #5 (sometimes a couple times) the signature was validated successfully. I have not yet found out the reason for this, since the uploaded signature files are valid if checked manually with GPG.


Much of the above information comes from this article in the Sonatype wiki. In the guide above, I added my own experience with releasing Maven artifacts so it should be easier for first-time users to follow.

5 Steps Towards an Accessible Web Form

Forms are the single most important element for user interaction in a web application. Without forms, a user can neither enter a search term on Google nor post comments on Facebook. So why is it that in many applications forms are so badly designed that they are barely usable by the common user and not usable at all for users that depend on tools like a screen reader? This article describes why accessible web forms are a benefit for every user and shows 5 easy steps to make a web form accessible. Impatient? Go straight to the slides or the github repository with the examples.

Why Accessible Forms?

When the term “accessiblity” is used in the context of a web application it usually conveys the meaning that users with some kind of disability like blindness are able to use the application. For me, the term “accessibilty” also includes the common users of an application. An application in general and a form in particular can be inaccessible even for a user who can see and use a mouse if it is badly designed. Take this form from, for example (yes, there is a website dedicated to exposing badly designed forms!). The values of the input fields are also used as their labels. If you tab into the field, the label simply disappears and you have bad luck if you forgot what the label was. Is this form accessible? Certainly not. It’s not even accessible for a user without disability! In more conventional terms: the form has bad usablity.

Since forms are a very important part of every web application, they should have good usability. Otherwise, the users will complain and the application’s acceptance will suffer. It’s not hard to make a form usable for all users, disability or not. The 5 easy steps described below go a long way towards making a form usable and accessible for everyone.

Step 0: The Example Form

The example used in this article is a money transfer form inspired by the online banking web application of my bank. It doesn’t have a pretty CSS design, but that’s not the point of this article. The form has some flaws from a usability and accessibility point of view which will be addressed in the following steps.

Step 1: Add <fieldset>s

The HTML <fieldset> element is an easy way to give structure to your form. Its only purpose is to provide a grouping mechanism for a set of input fields that belong together. A fieldset in HTML looks like this:

     <!-- put all input fields concerning the recipient of the money transfer here... -->

So what’s the benefit of having fieldsets? By default, you get a visual clue that some input fields belong together – giving structure to your form (you can make the fieldset invisible using CSS, though). What’s more, a screen reader reading the form to a user will now always read the <legend> of the surrounding <fieldset> to the user when he tabs into a input field. Instead of labelling the first input field in the example “Recipient (Name or Company)” you can now simply label it “Name or Company”, since it is clear that it belongs to the recipient. It just looks (and in case of a screen reader: sounds) clearer this way.

Step 2: Add <label>s

HTML provides the <label> element for defining labels for other HTML elements. This is insanely easy to do…all the more astonishing that it’s not used in important web applications (like my online banking):

<label for="recipientName">Name or company*</label>
<input id="recipientName" type="text" name="recipientName" />

Every input field should have a label of some kind. Otherwise, how is a user supposed to know what to enter in that input field? The <label> element simply adds some semantics to the label that makes it possible for tools like screen readers to find the label for an input field and read it to the user. Screen readers are intelligent enough though, that when they don’t find a <label> they will simply read the text in front of the input field. However, using <label>s gives you the flexibility of not having to put the label right in front of the input field.

You may notice that in the example form I also added <label>s to the “transfer reason” input fields which didn’t have any kind of label before.

Step 3: Add Field Hints

Some input fields require more information than just a label to help the user fill it out correctly. A good example for this are input fields in which the user is supposed to enter only digits. How is the user to know he is to enter digits if it doesn’t say so? Most users know from the context that a bank code consists of digits…some users don’t know this (for example when they are confronted with money transfer for the first time). Knowing they are supposed to enter only digits helps them to enter the correct information. Hints can be added to an input field like this:

<input id="recipientBankCode" type="text"
  name="recipientBankCode" aria-describedby="bankCodeHint" />
<span id="bankCodeHint">Please enter digits only.</span>

Just add some text right behind the input field to tell the user what is expected. To support screen readers, add the attribute “aria-describedby”. This tells them where to find the hint for a certain input field so they can read it to the user when he tabs into the input field.

The WAI-ARIA standard provides many more attributes like “aria-describedby” that add certain semantics helping screen readers to decide what to read to the user. However, simply using “aria-describedby” for an input field already goes a long way towards accessibility.

Step 4: Add “Required” Semantics

For some input fields the user is required to provide input, for others he is not. It’s an unwritten law to mark required input fields with an asterisk (*). It’s actually fine to do this – assuming it is documented in a prominent spot that your form uses this convention. Otherwise, users that don’t know what the asterisk means are lost. However, there’s a more elegant way to mark an input field as required:

<input type="text" name="recipientName"
  required="true" aria-required="true" />

The “required” and “aria-required” attributes actually do the same thing: they make screen readers read to the user that this field is required. What’s more, most modern browsers will also know that the given field is required and will show a message like “this field is required” if the user tries to submit the form without entering a value. It doesn’t hurt to use both attributes – this way even software that only knows one of the attributes will be able to tell the user that the field is required.

Step 5: Add Even More Semantics

With HTML5 came a bunch of new attributes with which you can add certain semantics to your input fields. Where there were only input fields of type “text” before, you can now add input fields of several types like number, date and email. We can now change the HTML of our “amount field” to the following, for example:

     aria-required="true" />
  <span id="amountHint">Amount in Euro.</span>

Note that the “type” of the input field has changed to “number” and we also added a minimum value and a step size that tell the browser and screen reader that you cannot enter a negative value and that the smalles amount size is one cent. If the browser supports the number type, the browser will show an error message on submit if the user enters characters that are not digits or decimal delimiters. Sadly, the screen reader I tested with (JAWS) did not read the “min” and “step” attributes to me. It still read “Transfer Details. Amount. Amount in Euro”, so actually nothing changed here from Step 4. However, we added more semantics that can hopefully be evaluated from future generations of screen readers.

Caveat: Limited Accessibility of Automatic Browser Validations

With steps 4 and 5 we added semantics to some input fields that cause modern browsers to display error messages when the form is submitted and the user has entered something that does not abide by those semantics (i.e. he entered characters when he was supposed to enter digits). This is a very nice feature for visual users. However, my tests with the JAWS screen reader and Chrome showed that these error messages are not read to a user relying on audio. Thus, when he submits the form, he gets no feedback whatsoever and may even think that the form was submitted successfully. Obviously, the browser and/or screen reader developers need to fix this. Perhaps this is only true for Chrome. However, I will look further into this and try to find a solution if the problem also occurs with other browsers.


The above 5 steps showed how to increase the usability and accessibility of an HTML form by minimally enriching the HTML markup. This is hardly a lot of work and will even fit in the tightest project schedule. As it is with everything in software projects (and projects in general): if you take care of the usability and accessibility of your forms right from the start it’s a lot cheaper than adding it at a later point in time.

Steps 4 and 5 should be used with the caveat in mind that they may result in automatic input validations by the browser which are not picked up by screen readers (at least not in the combination of JAWS and Chrome that I tested with). However, instead of abandoning semantics altogether, there must be a solution using javascript (coming up shortly).


I recently held a talk about this topic. Feel free to have a look at the slides. They’re available at slideshare.


How To free up Disk Space used by Oracle

The time comes when your Oracle database server has gobbled up a lot of space on the hard disk and you wonder why it still uses so much disk space after having deleted a lot of data from your tables. There is an easy way to shrink the size of Oracle’s tablespaces.

How much disk space can I save?

Simply execute the following statement to have a look at how much space your tablespaces currently occupy and how much space you could save. The statement provides you with the current size of each tablespace as well as the size you could shrink it to and the space you would save when shrinking it to that size:

select file_name,
ceil( (nvl(hwm,1)*8192)/1024/1024 ) SHRINK_TO,
ceil( blocks*8192/1024/1024) CURRENT_SIZE,
ceil( blocks*8192/1024/1024) -
ceil( (nvl(hwm,1)*8192)/1024/1024 ) SAVINGS
from dba_data_files a,
( select file_id, max(block_id+blocks-1) hwm
from dba_extents
group by file_id ) b
where a.file_id = b.file_id(+)

Save the space!

Then run the following statement to shrink a tablespace to a specified size.

alter database datafile '/path/to/data/file.dbf' resize 100m;


I found this very helpful hint at stackexchange:

Is Endurance a Good Quality in Software Projects?

The ability to endure hardship without complaining is often considered a positive feat associated with “endurance” or “stamina”. However, endurance seems to be a double-edged sword (not only) in software projects. An appeal to speak up in software projects instead of just enduring the status quo.

The Enduring End User

Everyone who has been involved in a long-running or a maintenance software project knows this type of end user. He has been working with the software day in day out for years and knows all the pitfalls and bugs. He also knows workarounds for most of the pitfalls. Those workarounds take more time than originally intended, but he doesn’t mind. He knows that the working day is over at 5 pm. So he endures.

While the Enduring End User is not happy about all the bugs in the software he works with every day, the Outspoken End User literally hates them. As soon as someone tells him about some new workaround to be used to dodge a new bug, he grabs the phone and calls the project manager to express his disappointment in the software and submits a request to fix the bug. If no one reports the bug, how will it be fixed, after all?

The Enduring Developer

The software developer finds himself in the middle of things when working on a software project. The end user confronts him with new requirements regularly. The project manager assigns tasks and wants to know when they are done. There is no real software development process established in the project, so the developer manages all the incoming requests as fits best. He wants to perform good, so he finishes his tasks quickly. He is not always happy with what he delivers but it is like this in all software projects, after all. So he endures.

Meet the Outspoken Developer: he speaks up when he realizes that he cannot complete his tasks in acceptable time and quality. He says “no” if the project manager wants to assign him additional tasks. He alerts the project team to the missing development process. He alerts them again when nothing happens after the first time. He may not always finish his tasks in the time expected by the project plan, but he will deliver better quality.

The Enduring Project Manager

The project manager has the task of negotiating between customer (end user in many cases) and project team. Both parties are annoying at times. Especially if they just don’t shut up and keep pointing out things that could be done better within the project. But he knows how to deal with those rebellious sentiments within the project. They just have to be endured until forgotten.

The Outspoken Project Manager, on the other hand, adresses the proposals of other team members and stakeholders. He talks them through and by discussing them finds a solution that the project benefits from in the end.

Endurance? Yes, but…

The above descriptions can certainly be transferred to many more roles in projects (and not only software projects) and they are certainly a little exaggerated. However, be aware that it is easy to fall into a mode of just enduring a project instead of actively participating in it since actively participating means to step on someone’s toes now and then… .

Nevertheless,endurance is necessary: How often do we delve in foreign code trying to find a solution to some wicked bug we just can’t get our head around? In a situation like this you have to keep calm and endure the time-consuming process of finding and fixing the bug. The important thing is to not just move on after this tedious bug fix. Ask yourself what the cause was that brought you into that situation. What can be done better? If you know something, speak up and talk to people about how to make it better. Perhaps even set up a white board where proposals like this can be posted and discussed in the team.