Recipe for getting the most value (measured in annoyance inflicted upon others) out of a superfluous meeting in the Software Engineering industry.

1. Discuss for the 12th time that your team needs to make test maintenance easier by reducing the amount of redundant properties in a configuration file.
2. Develop an approach for removing the redundant elements, building options up (with simple concatenation) from smaller parts so that less needs to change when a modification is required^**.
   • This approach should be agreed upon by all code maintainers and stakeholders as it will effect everybody, and will require the new approach to be adhered to in the future or the situation will revert itself.
   • The plan should be developed to satisfy criteria from test script writers, team leads, the maintainer of the automated nightly test run environment which has to override and work with many of the property values (i.e. yours truly), and test executioners (from both local platforms, and the central semi-automated execution platform). In our case, most people involved fill more than one of those roles.
3. Actually agree to implement this change and set a time for the work to be done instead of putting it off again (achieving this is made easier if your lead suddenly has to work with the unmaintainable file that you have been complaining about for over 6 months).
4. Rejoice…
5. Have a look at the implementation of the changes…only to find that the person performing the implementation has decided to make a couple of small changes to make it “easier” for them to run tests; which just happens to break the way employing systems (such as the automated nightly test run environment) work.

^{** Why we haven’t all been doing this from the start I will never know… I have for the properties I’ve added.}

The outcome…

Obviously, I’m fairly annoyed as I have spent a considerable amount of time pushing for this change to go in and was ignored or told that it wasn’t my priority. Then my lead finally becomes affected and tells us to make the changes but the task is given to someone on the team who only ever deals in their little space of test (and, is not much of a code architect). The implementer decides to totally ignore the planning and discussions we had waaay back on the previous day and do things to suit themselves!!

The result of this is that I now have to make some changes to the automated nightly test run environment… in fact, the number of lines of code will be 2-3 times that which was involved in the change to how the property file works (both sets of changes require a very small amount of code changes I’ll admit, but that actually makes it more frustrating that we spent so much pointless time planning this).

What was the change that was made post-planning?

Originally the properties were planned to end up looking something like:

some.property=myvalue
#some.property=anothervalue

The value needs to be different depending on what build version you want to test. There are 2 “standard” variants (most recent nightly build, and most recent production build) and doing it this way you just comment out the one you don’t want to use, and uncomment the one you do want. Simple and fast. The nightly automated system is a bit cooler in that it overrides the value to be any number of variations (the 2 standard ones, or any previous nightly or production build number, or even a custom build).

The implemented version, looks like this:

some.property1=myvalue
some.property2=anothervalue
use.property1=true

…not a lot of difference you may be thinking?

• The property now needs to be accessed through a method that evaluates the use.property1 boolean and returns the active value.
  • This method is not static and the encapsulating class requires significant setup.
  • Although most core test classes have an instance to the encapsulating class already, utility classes do not. These will now need to be modified (increasing the coupling) in order to access the property.
• The automated environment has more options, so I now have to pick one randomly to override and set the boolean accordingly.
  • The random selection to override will be very misleading (given the nature of the property names — the names I have used above have been generalized) to anyone reading the logs in the case of a failure.
  • If any test script uses that boolean directly (so, for any purpose other than selecting between the two variants) which is very, very likely to happen given the nature of its name, then there will be unexpected behavior when the test is run in the automated build.
  • Had we gone with the original method then nothing actually needed to be changed in the automated environment because it was already doing it this way (the system has previously been using a separate configuration file — we’re in the process of merging these so only one needs to be maintained)…test scripts needed to be changed regardless of how this was implemented.
• Changing the property still requires modifying the file so nothing gained there…in fact, it now requires more keystrokes!
• What happens if we ever need to add another standard variation? The boolean is no longer appropriate and code needs to be changed.

This rant isn’t so much about the fact that someone has ruffled my code feathers^##, but the fact that we wasted so much time in meetings so that this change would work for everyone and in the end it was written to suit the  sense of coding style of one person…with no other positive effect from doing it this way, even from his point of view. I could have made the change months and months ago with about 30 minutes of work if it wasn’t for the mandate that we plan and agree on how to do it.

^{## I have code feathers…deal with it!! I might explain this in a future post.}

I finally have a blog!

The reason it has taken me so long to cave and join the masses of Internet geeks who dribble on about their lives to nobody in particular is not due to any of the normal reasons, but from a problem I have as a Developer — I want to do everything myself. I can’t just grab some basic blogging software and set it up on a cheap/free host…no, I am totally compelled to write my own blogging solution which works the way I want it to work. I want to own, configure and create everything myself. Even in regards to hosting the site, I would be happier if I had to set up and configure the server myself. Because I can.

The more web-savvy among you have probably already noticed that I haven’t done this at all. This is a WordPress site, using a visual theme created by someone else. I haven’t done anything at all…this is true, and it is why there is an “anything” here for you to read at all. I had to make a decision about what to spend my free development time on: this site, or on more interesting projects (details might be coming soon). More interesting won, but I still wanted a blog. It hurt. A lot . There were tears.

If you build it, probably nobody else will even notice.

Now I come to the real point of my post. It is interesting how the desire to create can come out differently in people. I don’t care about writing poetry, sculpting, or painting a picture but I will be damned if I will use existing software for certain things (the more personal something is to me, the more driven I am to write the software myself). There is no ego behind this. I don’t have any delusions that I could create a better blogging solution than WordPress in my spare time…I could just create my blogging solution.

Software development has become an art. Not in terms of skill (in that regard it has always been an art) but in terms of enjoyment and ownership! Instead of building furniture, gardening, scrap-booking, etc…I code. I code simply for the joy of owning my own solution in the same way some people grow their own vegetables simply for the joy of eating their own food.

There’s an app for that!.. or will be once I find the time.

The problem lies in how versatile code is. To bring back the analogy of growing vegetables once again: a person who does this may branch out (no pun intended) into something like growing cows or whatever it is you outdoors people do, but is unlikely to try to grow everything. A developer on the other hand, can usually find something to build for anything and everything in life — I could write an application to track the growth and consumption of your vegetables, or to calculate the optimal placement for sun exposure in a given garden, to communicate with a moisture sensor so you will receive an email when you need to water the plants, or for any number of other purposes.

“A musician must make music, an artist must paint, a poet must write, if he is to be ultimately at peace with himself. What one can be, one must be.”
- Abraham Maslow

I can’t learn to do anything new without wanting to build software to facilitate, optimise, extend, integrate, analyse or in some way add value to the activity. I’m finding recently that in order to get anything done I need to choose which things are the most important and focus on that…maybe I should write an application to help me prioritise and focus.

I <3 you module x in namespace y!

I also find myself very affected by the concept of code-ownership, but not in a corporate, responsibility way…I become emotionally attached to my code. This is silly and something the very first programming lecturer I had explicitly told us not to do. Luckily, the reason for that warning from him seemed to be that sometimes you need to throw out your code and start again — which I will quite frequently, and happily do as long as I have the chance to rewrite it and become emotionally attached to the new version. So I think I’m safe as long as the languages I use don’t find out about each other and get jealous.