I was interested to see the post about Flickr’s developing new code on the mainline and using flags and flippers to control it.

Obviously an alternative to this approach is to use feature branches – so developing longer lived features off the mainline and only merging it back in when there you want to “turn the feature on”.

As Ross Harmes says though, “This style of development isn’t all rainbows and sunshine.”

So what are some of the tradeoffs requiring consideration before adopting this approach?

Pros

• Avoids multiple branches and thus merging – makes developer’s lives easier in that they know they are only in a single branch (mainline) and they need to keep that working
• Single codebase – force people to “fix forwards” rather than “roll back” changes.
• According to Ross,  ”Deploys become smaller and more frequent; this leads to bugs that are easier to fix, since we can catch them earlier and the amount of changed code is minimized.”

Cons

• Lots of “if … else …” constructs complicate the code base. As he mentions “after launching a feature, we have to go back in the code base and remove the old version (maintaining separate versions of all features on Flickr would be a nightmare)“
• Makes testing more complex with all these configurations needing to be tested
• If you are not careful, can lead to a certain amount of “copy and paste” coding as opposed to DRY style. This can require significant discipline to avoid.

As regards the “Deploys become smaller and more frequent”, this is possible to achieve with other methods, including task branches or the equivalent. Indeed I would say that making deploys smaller and more frequent is a desirable thing to do in any case.

The phrase “remove the old version” is very important – and implies a suitable amount of refactoring post release (and the discipline to make sure that happens). One of the things that I have learnt to appreciate more and more is the ability and the willingness to delete unneeded code (with the safety net of old versions being stored in my repository). You may comment it out line by line (a quick /* … */ around a block, while easy to do is very easy to miss when reading the code), but it’s amazing how quickly redundant code starts to slow you down and consume energy and brain cycles – especially for new people to that code. Keeping a clean code base through good refactoring has proven to be a very effective agile development practice for many people.

I have seen this flag approach used successfully in the past, but also seen it start to become a morass of spaghetti code when there are too many options, or when new features interact with each other (which is where “copy and paste” starts to become attractive, inspite of all its myriad failings and creation of maintenance problems). This is particularly true of “products” where there are lots of customisable options which need to be kept available to customers in the code base for years. Addressing this particular problem in a maintainable way requires a lot of thought and effort. Codebases in C/C++ with multiple #ifdefs can become a big problem if not very carefully managed. I remember seeing an excellent internal paper within Symbian on the half dozen potential approaches to introducing variability within their codebase for mobile phone systems (a harder problem than for many due to needing to provide source to manafacturers – so code changes are visible to others). The options ranged from #ifdef (very seldom considered as valid) to modular components to ordinary conditional statements.

A similar danger story was a company producing financial software for 15 different customers, with multiple different options, all from the same “codebase”, and indeed from the same workspace/development environment  (it had a database and 4GL involved which made it hard to create separate workspaces). If a customer wanted a new feature, they got it, but they were also forced to take 20 other features or bug fixes that had been checked in on the mainline and were requested by other customers. It often took weeks to stabilise things. Luckily things have improved substantially since then for that particular company.

This whole area has resulted in approaches and tools to address the problem – search for “software product lines” and “variant management” for some links. A friend of mine, Mark Dalgarno, runs Software Acumen who consults and sells products in this arena.

In the Flickr case, it would be interesting to get some metrics as to how many “features in progress” they have on the go at any one time, and how their development team tends to be split amongst features  (how many people per feature).

In the absence of such metrics to help people really understand the issues fully, I hope that the Flickr post won’t be a siren call which lures unsuspecting software developers on to a new set of rocks. As always, learn from others but make sure they are solving the same problem that you have to solve.

So, time to turn an early new year’s leaf over on the blogging front!

I have been struggling with some motivational issues as to making sure to keep updating the blog. Part of the reason for that is the tools I was using for maintaining the blog. The problem was that the tools I had and the interface to them were such that it became a bit of a chore to write new articles, upload them etc. Net result – I didn’t feel the temptation to blog much!

One of the reasons I went with Rublog (original blogging framework) is that I wanted to ensure that all my posts were appropriate version controlled – it is against my principles to have things “only” stored in a database when I am used to full version control (and various tools for seeing history of articles being stored).

Various other issues came to the fore as regards new features, comments etc. Having looked around, I realised that I had also been suffering from some code snobbery – my personal lack of enthusiasm for PHP (and preference for Ruby/Python), leading me to look askance at PHP based solutions. But tools are tools, and market share is as important in the blogging tool market as the SCM market – the more people using your tool, the greater the enthusiasm and availability of good options, addins, plugins etc.

So, the result is a conversion to WordPress. A bit of help from the redirection plugin and all the older articles should still be available!

The proof of the pudding as regards updates and the benefits of the new tool is in the eating, so watch this space for regular updates – keep me honest!!

A personal foible perhaps but I do find Ruby’s regular expression syntax remains in my brain much more easily than the Python equivalent.

Maybe it’s the Ruby inheritance from Perl that makes the difference. For simple scripts I can just write standard regexps without any recourse to documentation and they just work! For example:

some_var = "prefix interesting_match some suffix"
if some_var =~ /prefix (\w+) some suffix/
  interesting_bit = $1
  print "Match found: ", interesting_bit, "\n"
end

In order to do the same in Python I find myself faffing around with the documentation (using ActiveState Python it’s great to have a proper help file, but I would really like more links between the class reference and real examples of usage to help me out) and trying to remember if I want re.search or re.match and how do I get a match group and use it, etc. I have sundry Python scripts floating around that I open up and copy relevant examples from, but it does rather take time.

import re
some_var = "prefix interesting_match some suffix"
pat = re.compile('prefix (\w+) some suffix')
m = pat.match(some_var)
if m:
    print 'Match found: ', m.groups(0)[0]

Now I have to admit that it’s not a huge deal in terms of the resulting code, but it took me 5-10 minutes just now to code and debug the Python version as opposed to the Ruby version which I typed in and which worked first time.

The net result is that I am noticeably  more productive in Ruby for those little scripts that make life easier, or when I am under strict time pressure. Now this is not to say that I don’t like Python, or indeed that when I have a little more time I don’t get use it and enjoy it. Having done some reasonably significant work in Python, e.g. rework P4DTI for PVCS (now Serena) Tracker I feel reasonably qualified to comment.

I also took the time to get sufficiently proficient in Python extensions to enhance and maintain P4Python. Mind you I now feel somewhat humbled by the most recent efforts at a Perforce integration (PyPerforce) – shows a depth of Python extensions knowledge before which I can only bow in admiration! (Minor aside – Ruby extensions are much easier to write than Python ones due mainly to the different garbage collection models).

Finishing up, I am definitely Perl-averse these days. There are a few Perl scripts that I maintain and can’t be bothered, or can’t find a convincing “business” case to rewrite, but anything new is Ruby or Python.

I went to the 59 Minute Scrum session last October which sounded interesting – from the blurb:

“This session will give attendees a unique opportunity to experience agile practices first hand in a non-technical environment.”

I had good expectations but was left a little under-whelmed at the actual event. Now I have to admit that I arrived late and missed the intro so maybe it’s all my fault and the intro answered everything! (Discussion over a beer afterwards showed I wasn’t totally alone though).

The format was to split up into teams and discuss various scenarios. These were implementation projects including marketing, programmes and anything else we fancied on topics such as: a theme park around “spam”, a health club for pets and a space tourism project.

The event was fairly tightly timetabled so we had a slot to discuss our backlog, then split up further in our teams to actually come up with ideas on particular areas. Then round 2 for more implementation. Finally, all the teams (8 if I remember correctly – typically 2 per idea) presented their solutions to the whole group and touched briefly on how well they had addressed the backlog/made progress etc.

There was then an all-too-brief Q&A session at the end.

For me the format didn’t really work. I was left with too many questions and faffing about in the exercise had very limited benefit. I would much rather have had a well though through presentation on Scrum with lots of time for questions. At most half an hour of some exercises and then a presentation and lessons learnt would have worked much better for me.

Maybe I am just becoming a stick-in-the-mud?! I am likely to stear clear of such sessions in the future though unless there is time for a solid hour or more afterwards to get into details and ask questions.

There was a column a few months back on CMCrossroads on tool selecting, and these thoughts escaped our Agile SCM column for various reasons. Meanwhile, Brad has commented on his blog, so I thought I would weigh in too!

Agile SCM requires minimal disruption of flow to developer�s lives, and thus tools that help, not hinder, this process. The right processes are obviously key to effective and efficient development and it would appear that if you have a good process, then the more you can enforce it the safer life will be. However, as we wrote inThe Illusion of Control, too much safety leads to much reduced productivity.

As Joel Spolsky writes regarding defect trackers and enforcing process:

Historically, I am opposed to custom fields in principle, because they get abused. People add so many fields to their bug databases to capture everything they think might be important that entering a bug is like applying to Harvard. End result: people don’t enter bugs, which is much, much worse than not capturing all that information.

Best of Breed vs Integrated Suite?

This is a classic conundrum and there will always be good arguments for both sides. Indeed it is not possible to come down on one side or the other without knowing the details of a particular organization and all the nitty-gritty requirements.

However, let�s consider how some ideas might help us in our decision making process.

Who Owns the World?

Many tools make the mistake of thinking that they own the world � well at least the environment that they are going to run in. The user (developer) is going to be safely cocooned inside the wonderfully productive environment of the tool and never going to have to leave for the big bad world outside. Thus the vendors make little attempt to provide any interface to the outside world.

Now obviously considering that some things are �beyond the pale� has some advantages. Unfortunately the disadvantages are often considerable.

Over the years many vendors have come up with wonderful development paradigms, development environments, 4^th generation languages and similar which were indeed very productive. Often these environments included (very) rudimentary version control. The problem is that they implemented it badly (and often unreliably) and provided no hooks to external SCM tools which were used elsewhere in the organization.

This is a bit like the XP principle of YAGNI and refactoring as opposed to big upfront design. As Martin Fowler writes in Is Design Dead?:

People aren’t good at anticipating, so it’s best to strive for simplicity. However, people won’t get the simplest thing first time, so you need to refactor in order get closer to the goal.

Thus an attempt to anticipate everything developers are likely to need would seem to be rather difficult.

The rise of Eclipse which is making the basic environment a commodity with a good design for plugins and extensibility is perhaps a result of this worldview. Companies such as Borland are now repositioning previously standalone components such as J-Builder as add-ons to Eclipse rather than as competition.

This is somewhat similar to the arguments for performing builds using a general purpose language. The grand daddy of them all, Make, has its own arcane syntax and issues which have evolved and been tweaked and extended to try and solve the ever expanding set of problems posed by building systems.

In Martin Fowler experiences with Rake (a Ruby based build tool) he suggests:

The fact that rake is an internal DSL [domain specific language] for a general purpose language is a very important difference between it and [make and ant]. It essentially allows me to use the full power of ruby any time I need it, at the cost of having to do a few odd looking things to ensure the rake scripts are valid ruby. [�] Furthermore since ruby is a full blown language, I don’t need to drop out of the DSL to do interesting things – which has been a regular frustration using make and ant. Indeed I’ve come to view that a build language is really ideally suited to an internal DSL because you do need that full language power just often enough to make it worthwhile – and you don’t get many non-programmers writing build scripts.

My personal current favourite for such tools is Scons (written in Python) which has a similar approach that I have found to be very powerful.

Advantages of Integrated Suites

Of course integrated suites can be a big win if your problem domain is sufficiently close to what the designers had in mind. In addition, if the suite and its existing processes can be tailored easily to your requirements, then of course you should rate it highly in your selection criteria.

But you need to be careful. There�s an awful lot of �shelfware� out there consisting of tools sold as a �silver bullet� and never really used. The psychology seeming to be that if you pay enough money then the problem will be taken away from you.

Wolf Suites In Sheep�s Clothing

Then we have the category of suites that purport to be integrated but under the covers all is not what it first seemed. The classic example is of different tools which a company acquires by buying the original vendor, and with a lick of paint and a wave of the magic wand over the marketing materials suddenly has an �integrated suite�. The challenges of integrating tools not designed to do so are considerable and it can take many years for good integration to happen (if it ever does).

Customizability

Is also a two-edged sword in that you can spend all your time customizing the tool and not enough actually doing the work.

As has been noted by various people on CMCrossroads, workflows implemented by scripting can have a cycle of �script a little, test a little, repeat�. This would suggest that tools which offer the ability to design workflows graphically are immune from these problems. However, that is often not the case, and has been pointed out before, some of these workflow designers are in fact very difficult both to change control and to debug. A complicated workflow is an inherently hard problem to both comprehend and manage (which does point towards keeping it as simple as possible).

The key area of customizability is that of being able to link the tool (or suite) to the external world in the form of other tools. Thus providing sensible hooks to allow third party tools to link in would seem ideal. And yet this can be rather difficult to do in practice, and thus gets pushed to the back of the queue by the vendor. In addition, I suspect there is often a business rationale that they think if they don’t make it easy to link to external tools then the user will be forced to stick with the vendor’s tool.

It’s not quite on topic, but I could resist commenting on a classic example of third party hooks that don’t work very well – Microsoft’s SCC integration to Visual Studio .Net. This is based on a lowest common denominator API which used to be released under NDA but is now relatively freely available. It worked reasonably well with Visual Studio 6, but was totally re-implemented for Visual Studio .Net and rather badly it seems.

Conclusion

Thus I would personally tend to come out on the side of linking best of breed tools together rather than going for an integrated suite, since my experience is that integrated suites don’t try hard enough to provide clean interfaces to the outside world. Of course, some best of breed tools make integrations with other tools a bit like teaching a pig to sing – “frustrates you and annoys the hell out of the pig”!

So the real answer is that every potential customer for SCM tools needs to draw up their own requirements and evaluate against them. Delaying commitment by avoiding lock-in is a very valuable feature, but it doesn’t always pay off as it should perhaps in theory!

Do not turn brain off when choosing tool! An ounce of requirements analysis and evaluation is worth a ton of tweaking down the track.

I was at an event fairly recently where I did a short presentation on Agile SCM. During the presentation, I surveyed the audience about their awareness of agile development methods and practices and was rather surprised at the result. There were about 50 people, most of whom were very experienced developers who tended to be working on contract and were well up-to-date on Microsoft tools etc.

Remarkably few had even heard of things like XP (eXtreme Programming), FDD (Feature Driven Development), SCRUM and DSDM (for example 3 people said they were doing agile development and another 3 or so said they knew of it). That said, when I went in to some agile practices such as continuous integration another half a dozen put their hands up.

There are a couple of responses to this:

• There is a marketing problem for Agile Methodologies
• Developers are not keeping up to date with the industry

Regarding the first response, I think that this is progressively being addressed through internet articles, books, seminars etc.

The second perhaps shouldn’t have surprised me so much, although it did. It would appear that there are a large number of developers and others involved in software development who just treat it as a job – go to work, do it, go home. They seem to keep their heads down, not read magazines, articles and related things, and basically not stay abreast of developments in their industry. These are bright and clued up people technically! But think of a dentist who didn’t keep up-to-date – how long would he or she keep their patients? My dentist has his certificates of “continuing professional development” up on his wall – it gives me a good feeling when I’m lying in the chair!

I think that professional development is a pre-requisite for anyone in any field. And excellent treatise for software development is Dave Thomas’s “How to Keep Your Job”; and a couple of useful points at Coding Horror: Be Good at your Job. An interesting take is How to Prevent Offshoring Taking Your Job

Perhaps on a related note I can singe the praises of the geographical and specialist groups – the people that I see attending these meetings are the ones who will do well. The BCS provides some excellent professional development support to individuals and to companies.

I’d also like to put a plug in for Toastmasters International – a global organisation for improving your public speaking skills. I have found it very useful myself (and can recommend London Corinthians for those who can get to Victoria!).

One of my background tasks requires administration of bookings for conferences or events. I created an online registration form with javascript validation of credit card numbers and other sundry checks, and if the user submits a registration it is stored as a fairly simple text file on a secure server. The problem I had was to access the secure server forms for plugging stuff into a database etc. For a couple of events, this has all be done manually by my administrator – somewhat of a pain, especially if she was away and we were close to the event and I had to process them myself!

My attempts to automate this were stumped by https access (using OpenSSL). Some brief trials in the past with Ruby failed dismally. I even managed to download OpenSSL and build it and install the Ruby extension – all seemed to work fine but I couldn’t for the life of me manage to successfully login and get the contents of a web page from my secure server. Frustrated, I put it on to the back burner at the time.

Just recently I noticed that the latest Ruby One-Click installer now included the OpenSSL module (which saves lots of hassle, especially as I had had to reinstall my laptop losing the previous OpenSSL installation). This prompted me to search again for examples of how to use it, and this time I eventually turned up a sample from the new Programming Ruby 2nd Edition.

This worked straight off the bat for me and allows me to proceed with the rest of the processing. This is likely to include parsing of the text into an Excel spreadsheet or even Access database.

Code

This is it:

require 'net/https'
USER = "xxx"
PW = "yyy"
site = Net::HTTP.new("www.securestuff.com", 443)
site.use_ssl = true
response = site.get2("/cgi-bin/cokerecipe.cgi",
             'Authorization' => 'Basic ' + ["#{USER}:#{PW}"].pack('m').strip)
print response.body

Easy when you know how!! Thanks to the Pragmatic Programmers!

I have organised a few events over the last year or two.

Activities

The main activities I have found that work for a successful event, are:

• Decide you are going to have the event (and roughly what sort of thing it will be)
• Pick a date (hopefully far enough in the future)
• Identify things that need to get done to make the event happen (broad brush works fine)
• Work backwards from your date and work out intervening milestones
• Delegate activities
• Work your plan and make things happen!

This is really about project management – lots of lists being generated, tasks being ticked off etc.

Begin With The End in Mind

Best said in Steven Covey’s “7 Habits of Highly Successful People”. The more you know what you want, the more likely you are to get it. The key work of “leadership” occurs at the start of the process.

The interesting thing I have found is that a kind of internal change happens for me – a “knowing” that the event will take place. In some way it is a personal commitment that I will make it happen (for those events I have been prime organiser for). This is strengthened by setting a date (and usually getting the agreement and commitment of some other people on the relevant committee). However, it seems to be more than just personal. Perhaps it is just what has been noted elsewhere “the moment one definitely commits oneself, the providence moves too” Goethe (very freely translated).

The personal commitment brings out help from others, and provided that you put the work in to hit milestones along the way, things happen.

Goals

I have had less success in other forms of goal setting for more abstract , but having been thinking about this to the extent of writing this entry, I am working on ways to apply it in more abstract settings.

Having been on a few volunteer committees, my rules of thumb are:

Commitment Breeds Rewards

Putting your hand up to be involved and active on a committee is a great way to get started, and truly magnifies what you get back.

There’s nothing like a few committee meetings to start to get know people. That then leads to all sorts of links, tie ins etc. Even a brief spell on a committee can reap you benefits for years afterwards. Read Alan Weiss (”Million Dollar Consulting” and similar books) for some ideas on this.

Only a few people actually do the work

There are always a few key people who actually do the work. Find out who they are and work with them. The old saw about getting something done by giving it to a busy person, is oh so valid.

Ideas vs. Actions

A corollary to the above – lots of people have great ideas for this, that and the other. When it comes to implementing the ideas, the idea generators are not to be seen. If I am organising something then I always treat ideas as “nice to have” until someone signs up to take responsibility.

Pretty much any implementation, however bad, beats any number of virtual ideas.

Sustainability

Groups wax and wane according to the needs and energies of the committee and the members of the group. Decisions that are taken need to have at least half an eye on the future, and in particular how sustainable something is. Activities such as maintaining a web site need to be done with technology such that some else can take it over in the future. Using a specific tool just because it is convenient for you or you have access to it at work, leads to you not being able to hand it over.

Which Groups Should I Belong To?

There comes a time when a group becomes much less useful to you, and it is time to move on. Re-evaluate groups and commitments regularly (perhaps a couple of times a year), and change when appropriate. This is an idea I got from life coaching – evaluate activities and work out if they are energy boosters or energy drains for you. Remove the drains!

One of the key XP (Extreme Programming) Practices is that of Pair Programming � two programmers working side-by-side at one computer collaborating on the same design, algorithm, code or test. The XP advocates state that higher quality products are produced faster, inspite of what appears at first sight to be an overtly redundant, wasteful use of programming resources.

The interesting thing that I have found is that when I teach SCM training courses with hands-on exercises (where people work through exercises against a pre-prepared repository), I usually get much better feedback and results if those present do the exercises in pairs.

Benefits

The advantages that I see are:

• a higher level of “hubbub” in the room – an indication of information exchange and reinforcement, resulting from more discussions both within and between pairs
• greater willingness to ask questions of the trainer
• faster progress through the exercises

My feeling is that pairing gets over a variety of inhibitors. It is quite easy when doing exercises to get stuck thinking you ought to know the answer (usually in the materials presented in the last session), and people work away for quite long periods without progressing. More importantly from a trainer’s point of view, people are often somewhat reluctant to ask questions and thus show that they have a problem (this tendency can vary significantly between different nationalities).

There are other factors at work:

• if there is an active internet connection available on the machines then individuals are more likely to surf the net or check their emails than a pair
• a pairing of more/less experience people brings greater knowledge transfer

Disadvantages

Some people find it inhibiting to work in a pair. They have a certain learning style and this doesn’t mesh well with their potential partner. Also, levels of experience can vary quite widely, leading to boredom and less learning for the more advanced person (though usually with benefits for the less advanced).

Some people prefer to be able to take detours and investigate functionality on their own, and are inhibited from doing this in a pair (which is a shame).

Applicability

Pair exercises work extremely well for in-house courses where all those present work for the same company. They usually know each other and are able to pair up easily and quickly.

Not surprisingly, I do not find it so applicable with public courses where only 1 or 2 people per company are present, and the level of preparation and relevant prior knowledge and experience can vary significantly among those attending.