Introduction
I strongly consider that the following three items are of high relevance for software project quality:
In this article I will give an overview of them, providing some personal experience about each. Continue reading
Startups and The Problem Of Premature Scalaculation
One of the reasons why startup founders so often spend too much too soon on scalability is that it is satisfying to do so. You can spend resources and have something to show for it. It is also easier to take credit for tangible progress. “Hey, we just tested the system last night with a million users and it didn’t crash!”. Or, “We just upgraded our hosting infrastructure so we can guarantee our users 99.999% uptime!” It’s also useful to tell potential investors. However, it is much harder (but usually much more meaningful) to spend resources on things that are not quite so black and white: like learning about your market, putting a few more iterations of the software out there, finding more users/customers. All of these kinds of activities are much more frustrating because they’re so much harder to control.
If you haven’t tried git, you should. Git is a “distributed version control” system, that is, similar to Subversion with the big difference that… you do not need a server. There are only clients, any of them, and you can pull and push changes to and from other repositories from your project colleagues. The git Wikipedia entry does a much better job than me to introduce the subject :)
In Mac OS X, I’ve just downloaded the source code tarball with the latest snapshot of the code, and it compiled out of the box. Just the classical operations:
./configure make sudo make install
Then I went through the tutorial, and frankly, I loved it. The Everyday GIT Guide is excellent too to understand the idea of this beautiful piece of code.
It’s too cool, really. Lightweight, and damn fast. No wonder why everyone’s talking about it lately!
Another open space! Wheeeeee!!!!!
We’re going to be building out the space to create a environment really optimized for our great engineers, product managers, web developers, designers and quality engineers to all sit and work together. Very high energy, with a lot of thought given to providing the best possible place to design & build the features for the world’s largest professional network. When the space is done in a couple of months, we’ll have room for another 120-150 people, and we’ll post pictures of the launch. But as a teaser, here is a quick 3D rendering of the type of stations we’re planning for the space:
What I find hard to believe is that the guy actually uses the word “teaser” for the most horrible, common, mediocre of office space setups, one that you can find (and suffer) anywhere on Earth. And 3D rendering? 3D RENDERING? They’ve used a CAD program to do a photo that you can find in any IKEA catalog?
This article is absolutely amazing. The more I read it, the less I understand it. Hasn’t anyone read Peopleware? Geez.
In Buenos Aires I’ve studied corporate management (I did, shame on me), and as part of that, I had to learn about all the different identified types of organizations: matrix-based, pyramidal, military, organic, etc. Afterwards, books like Peopleware made me rethink these concepts, particularly when seeing the pityful state of some software development companies here and there.
I mean, except some unusual exceptions, our work environments typically suck. Deeply. Nobody gives a damn about your ideas, and you’ll just have to sit there in crowdy and noisy open spaces, and do the stupid things that you’re told to do, and everything is a horrible command and conquer experience. Working in this free market, post-Berlin wall world, the only choice you’re left with is suck it up or leave.
Welcome to the free world. You’re free to starve or to choose who to submit your soul to during 40 hours per week.
In the software development field, changing jobs is a comparatively easy thing to do, with the few exceptions of the software crisis in the mid 70s, at the end of the 80s and between 2002 and 2004, but in any case those crisis happened during short periods of time. But in other industries, people, for many reasons (mortgage, family, etc) they have to stick with horrible workplaces, awful jobs, incredible amounts of stress and awesome levels of burnout. Why does it have to be this way?
And you know what? It doesn’t have to. Some company out there, in a more “brick and mortar” industry than software, thinks that the current way of doing things is wrong. If you haven’t heard about Ricardo Semler, go and watch this movie from the MIT. It is amazing. This guy, CEO of a industrial company in Brazil for the last 25 years, has totally changed the way things are done, and brought some extremely innovative ideas to his company, which has since sustained a 900% growth (!) with as little as 2% turnover (!!).
Now go watch it (it’s only 40 minutes long), and I hope, learn something. I think that the Swiss business environment really needs to change, and Semler’s approach might work. And by the way, the guy is really funny!
Don’t miss this! (local copy here if the server is unavailable)
The best time to test is when the code is fresh Your code is like clay. When it’s fresh, it’s soft and malleable. As it ages, it becomes hard and brittle. If you write tests when the code is fresh and easy to change, testing will be easy, and both the code and the tests will be strong.
Howard and LeBlanc give a very complete answer to this question in their classic “Writing Secure Code” book:
Most testing is about proving that some feature works as specified in the functional specifications. If the feature deviates from its specification, a bug is filed, the bug is usually fixed, and the updated feature is retested. Testing security is often about checking that some feature appears to fail. What I mean is this: security testing involves demonstrating that the tester cannot spoof another user’s identity, that the tester cannot tamper with data, that enough evidence is collected to help mitigate repudiation issues, that the tester cannot view data he should not have access to, that the tester cannot deny service to other users, and that the tester cannot gain more privileges through malicious use of the product. As you can see, most security testing is about proving that defensive mechanisms work correctly, rather than proving that feature functionality works. In fact, part of security testing is to make the application being tested perform more tasks than it was designed to do. Think about it: code has a security flaw when it fulfills the attacker’s request, and no application should carry out an attacker’s bidding.
(Howard & LeBlanc, 2003, page 568). Continue reading
Introduction
Even if Design by Contract is a trademark (Eiffel Software, 2007) the idea behind it is the more general one of “defensive programming”. As software developers, we often concentrate our efforts in the main code of the application, which is the interesting part, and that provides the realization of the use cases identified during the early phases of the project.
My opinion is that defensive programming techniques lead to more secure, stable, and less bug-prone code, and that they require less documentation, since the resulting code is more “self-documenting”. Moreover, I will describe in this paper language-independent techniques, that can be used in different situations and systems, that are somehow similar to the Eiffel approach.
Mercury TestDirector for Quality Center is an enterprise-class solution, recognized as one of the most complete and integrated software suites geared towards the management of testing- and quality-related activities. Mercury Interactive, the company behind TestDirector, was bought by Hewlett Packard in 2006 for USD 4.5 billion (Wikipedia). TestDirector is used by several important organizations such as Nextel, the United States Navy, Nestlé, Qualcomm and Shell (Mercury Website, 2007a). Continue reading
Introduction
The explosion of the Columbia Space Shuttle uncovered several internal problems in the National Aeronautics and Space Administration (NASA). This paper will summarize the reasons of the accident, highlighting the organizational issues, and provide an overview of the roles played by the different stakeholders of the project.
