Very good interview with Scott Bellware regarding Ruby and Rails and his thoughts on the MS community. I think he talks for many of us about what we encounter frequently when talking to developers and the general .NET community.
Terminal 2, which is mostly European destinations has had a change in policy at the security checkpoint, and unless it’s part of a staged change, it somewhat baffles me. All airports ask for you boarding card just before you put your bags through the security checkpoint. Unless you’re traveling to a destination that requires passport control, they don’t ask for your ID, just your boarding card. They normally check to make sure the date and origin/destination airport correspond to when and where you’re boarding. It’s a real fast check. No other measures really required.
However, with the introduction of online check-ins and auto-checkins, they now verify your identity at the boarding gate, making sure the name corresponds to that printed on the card. Many people have written ways to workaround this issue and I’m not going to talk about that. What baffles me though about the change in FRA is that now, before you pass security, instead of them just looking at your boarding card, they’ve added an extra layer. They are verifying it on the computer. I assume this is to make sure that the flight number exists and corresponds to that printed on the card. They still however don’t ask for your ID. This is done when boarding. Now FRA normally has queues to get though security and sometimes it gets really long depending on the time of day. This step is just adding more to the already large bottleneck that the security checkpoint is, and yet doesn’t provide that many advantages. If they want to add an extra security layer of verifying the ticket number and other information that would be "hard" to come by, why do it at a central point? Why not distribute the load between the different boarding gates. They already take an extra 5 seconds to verify the ID matches the ticket, why not do the boarding verification there too? Plus, unless it’s a home-printed boarding card, all "normal" boarding cards have a magnetic strip that goes through a machine that checks the data on it.
It’s become common for me to be delayed on Iberia flights, specially those going to Frankfurt*. So while I’m sitting here waiting, I thought I’d write up something I came across today as I was arriving to the airport. It’s been just over two months since I last traveled, and my home town airport, Málaga is expanding. They are expanding the parking, the terminal and even adding a new runway. Today, as I arrived, and having taken the train in, walking over the walkway that crosses the main road I managed to get a "half-flying-birds-eye-view" of the whole surroundings. It was amazing. There were over 10 cranes (those that I could count), scaffoldings, workmen, diggers and everything you could think of that you would find on a large building site. The roads were all turned up, there were half-done pillars for bridges in the works, there were temporary pathways set for pedestrians and a whole slew of other things.
Now, during all this time, the airport has remained operative. I haven’t checked the numbers but as far as I know Málaga is probably the 2nd most transited airport in Spain. So all these reforms have to be done in a way as to not disrupt too much (it’s virtually impossible to have no impact, considering for months one of the parkings was moved around 3 km away from the terminal building) passengers and in general users of the airport. That in itself has merit. However, what really fascinated me and made me think about topics like integration and teamwork is how each person or group of people were working on different sections and eventually all of them will come together. It may not sound too difficult, but if you’re like me, that can’t put a shelf on straight or even hang a mirror, it does amaze you.It’s an enormous puzzle that has to fit perfectly when completed. There might be adjustment, there might even be changes during the development phase, but at the end of the day, we have a pretty good outcome that is productive and provides a good user experience. It’s mostly planned and outlined from before and then executed but still, that doesn’t imply that it’s easy or there are no changes along the line.
And yet as software developers, we continuously moan and groan about how our profession is so much different than others. They say you can’t compare building a bridge to software development. It’s usually based on the premise that customers do not know what they really want and how requirements change. The end user of a bridge is usually the general public. However, they aren’t the ones that decided to build the bridge. It was a decision taken by either the local or state authorities. In Spain for instance, the "Ministerio de Fomento" is the governing body that normally takes care of these things. I’m sure the minister doesn’t know his/her exact needs. She has a team of consultants to work with. Authorities, architects and engineers work alongside each other and based on surveys and requirements plan out the project.
With software, it’s a similar process. Our jobs as software developers / consultants is to help and guide the customer with their needs. The problem is, we have to be a jack of all trades. We need to not only know about our profession but try and understand as much as we can and in short time the customer’s business. And this raises the question: how much of the "the customer doesn’t know what he/she wants" is really correct? What percentage of that is "I didn’t understand the customer correctly" or "I didn’t convey the customers needs appropriately" ?
Miscommunication between parties is not the sole cause of why many software projects fail. Bridges and businesses are different in that the first is stagnant, it doesn’t change over time, whereas many businesses can and usually do. Businesses are tied to the market. Markets change and businesses need to adapt. So there is a factor in there that as time goes by, software needs to evolve. However, the main reason is still the lack of understanding between the parties involved. If we plan appropriately we can adapt to changes without raising the costs too much and agile methodologies are crucial for for this. With techniques such as continuous integration and testing we can make sure that things fit together before the project is complete. This is something workers on a construction site don’t have the luxury to poses. They can’t place a concrete block down and if it doesn’t fit dump and re-do it again. So when you think about it, our job is not that much harder than other engineerings. In fact, in many aspects it’s easier.
*[Update: Typical. I missed connection in Madrid and had to spend the night in a "4-Star" hotel Iberia provided. It was 4 star because the inspector is too afraid to go back there and remove 3 of them. What a dump!]