It’s the people, stupid !

The boost community has recently been shaken by an announcement of the steering committee to move from its current build infrastructure (based on an in-house tool) to CMake. Discussions about such a change have been going on for years, and the SC, noticing that these discussions didn’t go anywhere, decided that it would be in the best interest of everyone to impose a dicision.
Now the “only” remaining question is how to get there, by asking volunteers to implement the change. This has expectedly resulted in a lot of heat, including the departure of a key member of the team developing and maintaining the existing build tool, leaving the whole project in a disarray.

I’m myself maintainer of two Boost libraries, and thus have strong opinions about the best way forward. But what I’d like to note here is a more general pattern I have been observing in many different places. And it’s about how people conceive of “software”, even within the industry, people who should really know better.

Software is considered to be a thing, something that can be changed (broken, fixed, improved, etc.) by applying a “patch”. So it’s natural to think of “resources” and “jobs” as entities needed to move from state A to state B.
Others think they have done everything possible to make their software “optimal” (not to say “perfect”) to solve a given problem, so there is no possible reason for wanting to change it, as that would by definition make the software “less good”.

Now consider software as a reflection of our understanding of a given problem, a manifestation of processes and practices – short, a cultural artefact. There can be many reasons to change. The problem we are trying to solve may have changed, or our understanding of it may have evolved. In either case, it doesn’t make sense to think of change as merely a patch to be applied to software. It’s first and foremost a procedural change, a change that needs to be agreed on and embraced by the very people who work on and with the software, before it can be embodied into software.

Software is a means, not an end. And software engineering really is applied epistemology.

 

Advertisements

OMG !

No, that’s not the acronym you are (likely) thinking of. That’s the Object Management Group, which just held its quarterly Technical Meeting, in Burlingame (near San Francisco).

As a rather turbulent week draws to an end, I’m walking through a slightly rainy San Francisco to take in some more local air.

From San Francisco 2012

At the meeting I broke a couple of records. One, notably, for having brought a (preexisting) set of specifications through the OMG standardization process to full adoption within only 9 months. (We started the initial RFC process at the March meeting in Reston.)

The second, for being the first to submit specifications using DocBook. While this has been a “supported” format (together with FrameMaker), I’m apparently the first one to actually using it in this context.

Most people still submit MS Word documents (yuck !), resulting in a lot of post-processing by OMG’s own editor to massage the text into  OMG / ISO – compliant formats. As a result, the submitters are no longer able to maintain their own specifications, instead requiring OMG’s technical writer(s) / editor(s) to apply their patches for them. What a wasteful process.

By using DocBook, our community is now enabled / empowered to maintain the standard ourselves, which makes everyone involved, as well as (and in particular) those who no longer have to be involved, very happy.

On Wednesday I met with a couple of my colleagues, who happen to live in the area, to celebrate the completion of the above work, as well as to talk about the future.

I also took the opportunity to sneak in a few hours to visit the Muir Woods National Monument, which, by exposing me to an entirely different scale of space and time, relativates many of the other things running through my head.

From San Francisco 2012

Now I’m sitting in a *$ (read: Starbucks) as I have a few hours before my plane takes me back home.

Las Vegas Adventure

After a rather inspiring (yet exhausting) week at GTC, I’m on my way home from San Francisco to Montreal. I had chosen to fly via SFO instead of SJC, because the connection appeared to be slightly better. On my flight from YUL to SFO, the crew encountered a “minor” technical issue, and chose to land in Denver instead of San Francisco. While we were supposed to take off again within an hour, we sat on the tarmac for >3 hours, when it was announced that the problem was bigger than originally thought, such that the plane could only take off the next day.

I managed to get a different flight to SJC, to arrive 12 hours late at my destination.

Now I’m on my way back, taking a two-leg flight from SFO via LAS to YUL. Arriving in LAS after 22:00, it’s apparently too late to have anyone in the terminal who can give useful information. When I finally figured out where to go to get the connection flight, and make it yet again through security, the plane is already taxiing towards the runway. So I’m stuck in this unfriendly, noisy, and inhumane place (which ironically claims to be the Mecca of the Western world) for the night, .and be home in Montreal 12 hours late.

This makes me miss a concert I have been looking forward to see for months. How annoying…

Vernal equinox

Spring is here !

Google just published the list of this year’s GSoC mentoring organizations. DocBook will participate for a first time, as will (as usual) Boost. If you are interested in any of this, don’t hesitate to get in touch !

I have also started looking into switching to CLang as Cpp/C/Cxx parsers for Synopsis. While this looks very promising, there is still quite a lot of work that needs to be done before this will be usable. Any help is highly appreciated.

Google Summer of Code

A too short and too rainy summer has almost passed by in a blink of an eye. I mentored two GSoC projects this year. One of them, adding Python 3 support to boost.python, was very successful, and I just merged the changes into trunk. As I don’t expect any surprises there, I’m sure the code will be ready for inclusion into the next release. Yay !

The other project wasn’t quite as successful. Not only did it require a lot more hand-holding from my part, but it didn’t result in nearly as much improvements as we had hoped for.

Neither result came as a surprise. In fact, I probably could have predicted it when reviewing the applications. But as I’m an optimist, I always hope for a better outcome, even if there are warning signs. As I will participate in this year’s GSoC Mentor Summit, I’m sure I will hear from other people what they have to suggest as to how to evaluate proposals to avoid surprises.

Synopsis

Today I made a new Synopsis release. Its main feature is an updated Cpp processor (aka. ‘preprocessor’) which is able to annotate macros and cross-reference them, just as Synopsis does with C and C++ declarations.
I updated the ucpp version that is used as backend. Hacking the required support hooks into that was surprisingly delicate.
Unfortunately, ucpp’s author and boost’s preprocessor experts disagree on the interpretation of the CPP specification, resulting in it not being able to process an important part of boost correctly.
A couple of years ago I attempted to use boost.wave as an alternative Cpp processor backend. Unfortunately, that has its own share of bugs, which very much restrict its usefulness, at least for applications such as Synopsis.

Roundup

I have recently completed a 1-month sabbatical that allowed me to work on Roundup. A big part of that consisted in pushing upstream lots of small (and occasionally not so small) fixes and enhancements that we developed at CodeSourcery. (For example, we dramatically improved performance for serving (large) files.)
I also worked on the XMLRPC frontend (hoping that this will allow customized client applications to be written).
Overall, I’m very happy with this work. As I knew I was going to work on this, I started by rewriting the Roundup website (discovering sphinx in the process), and migrating Roundup’s own bug tracker away from sf.net, near the python.org tracker. (We are finally self-hosting !)
The desired effect was to help revive the Roundup community (both, user and developer). It seems this worked well: now we even have a candidate project for this year’s Google Summer of Code !