gpollice

Archive for June, 2010|Monthly archive page

Manifesto Mania

In Software Engineering on June 28, 2010 at 12:59 am

I don’t know about you, but I think that the manifestos have lost their allure. Most of you may know about the Agile Manifesto, but do you know how many other manifestos are out there? I think we’re seeing an epidemic.

The Agile Manifesto has had one of the biggest impacts in recent years. Seventeen well-known software developers—most of them consultants—got together in 2001 at a ski resort in Utah to try to draft the manifesto. They wanted to identify common ground in what they offered as value to their customers that distinguished them from other consulting organizations, especially  large organizations like Rational Software, IBM, and so on. This was a period where, like today, many trade conferences had sessions delivered by such experts that told the audience how to build better software. There was a lot of wisdom in what they said and there was a lot of differences and in-fighting to push their ideas forward as the best of the bunch. But there certainly was the common ground that most of them were from relatively small organizations who were competing with the big guys and that made it hard to get a foothold in customer organizations.

This post isn’t really about the Agile Manifesto though. You can read about the history of the manifesto and other good things in the above link. The key point is that the Agile Manifesto was important and had an impact upon the software development scene back then.

Like most good ideas, they get copied to the point of overuse. That’s what I believe has happened with the manifestos. Consider the following that I found in just a few minutes searching on the Web.

OK, that’s enough. You get the idea. It seems like anyone can create a manifesto and probably get some others to sign up for it. Unfortunately, the number of manifestos out there have diluted the space and lessened their impact.

One of my pet peeves about software development trends is simply that there is so little empirical data available to back up most of the claims that people, and especially business entities like tool vendors and consultants put out. Therefore, I have my own Manifesto.

Anti-Manifesto Manifesto

As an old curmudgeon who’s seen too many fads and useless—or worse, harmful—practices that are blindly followed without fully understanding them, I have come to value:

  • common sense over blindly following a process, any process
  • empirical results over unsubstantiated claims, even if they’re made by someone I respect
  • solid principles over trends and fads
  • clean code over cute tricks that obscure the meaning of the code

Therefore, I vow not to read anymore manifestos.

POSSE retrospective

In OpenSource on June 12, 2010 at 9:00 pm

Well the POSSE Worcester session is over. It was a good experience and I got to meet some very interesting people. We finished up yesterday with a discussion of some educational issues, both pedagogical and practical. I gave a short overview of my WPI Suite project. Although right now, this project requires membership to the SourceForge Enterprise installation at WPI to get to the source repository, you can go to the site and download the file releases to try it out. If you’re interested in getting the sources, send me a message and then apply for an account from the site and I can approve it. I’m hoping that by the end of the summer we’ll have it set up much better as an open source project.

Today I finished the code on the Measure Activity and pushed it to the posse-clone branch. If there are no other changes by Monday evening, I’ll get a merge request to Walter. Unfortunately, testing Measure in Sugar on Fedora (in VirtualBox) has been difficult. There are a lot of problems that show up that have nothing to do with the code we’re working with.

Anyway, there was a very simple way of implementing the timer task. It was using a simple Timer object from the Python library.  Once the user clicks the record button, the code now creates a Timer object that fires after the appropriate delay. When the Timer fires, it causes the sample to get logged and creates another Timer before exiting. This goes on until the user stops the sampling. When that happens the current Timer’s cancel() method is called. Simple and it works fine. I think we made some definite improvements to Measure. I don’t know if I’ll have much time to work on it this summer since I have to finish my software engineering textbook, get WPI Suite V2.0 out, and get ready for school next year.

POSSE Day 4: Getting to E

In OpenSource on June 11, 2010 at 1:22 pm

After starting the day spraining my ankle as I left home, it could only get better. We continued hacking Measure. Adding the timer task is moving along. The code isn’t very well organized and there are some duplications we’re removing. The big problem, once you find where to put things in is getting the timer thread to work. We started by looking at an example from Geoffrey Foster, but that is a blocking thread.

Before breaking for the day, we thought about using a Timer object from the Python library. The documentation is not great on it, but when I asked my friend and former student Tom Rybka who’s now at Google about it, he did a little checking and told me that Timer seemed to be non-blocking.

We just haven’t had the time to implement it. We had a productive discussion in the afternoon about education issues (the E) that we’ll continue tomorrow.

Instead of joining the group for a nice dinner I went home and iced my ankle and didn’t work on the code at all. Maybe we’ll get the threads working tomorrow.

POSSE Day 3: Taking the measure of Measure

In OpenSource on June 9, 2010 at 11:04 pm

So today we started work on the Measure Activity. It certainly needs work. The idea behind Measure is really nice. The user can use a sensor or the microphone and capture data from them. The actual data is written to the journal, probably not in the best way, but it’s there. The data can be imported into other applications for analysis.

My partner, Mihaela and I started working on ticket 1911 from the Sugar bug tracker. There are several problems we uncovered while trying to understand the code enough to reproduce the original problem and understand what the application was trying to do. Here are the things we discovered.

  • The pull down that shows “Now”, coupled with the button whose tool tip says “Start Recording” are terribly misleading It implies, as the author of the ticket seems to have understood, that the Measure will begin recording data when you press the button and stop recording automatically when the specified time ends. In fact, the time is the interval between samples and this goes on until press the button again.
  • Once you realize that the interval is correct, it actually doesn’t represent the right amount of time between snapshots. The code uses a counter and the counts are wrong. This may be due to different processor or microphone sensing rates.
  • The tool tips are quite misleading and do not exist on all of the controls on the toolbar.
  • The behavior of Measure is rather fragile. We had it crash a couple of times for no obvious reason. It also hung after we put in a debug statement, but then when we brought it back up, it worked fine. Also, when we tried to quit, the Activity asked if we wanted to keep (the entries?) it came up with a “Keep error.” This too went away mysteriously. But that’s for another day.

We’ve made quite a few changes. We added appropriate tool tips to the combo box that contains the sampling interval and to the button that starts and stops the sampling. We also changed the text in the combo box to be more descriptive and removed the choice that did nothing. Next we tackle the harder problem of controlling the timing for taking the snapshots into a timing thread.

POSSE Day 2: Getting into the code

In OpenSource on June 8, 2010 at 10:35 pm

So, today we got into the Python code for one of the Sugar Activities: abacus. Adding a new abacus to the code was very painless. The code was quite readable—at least for the things we needed to do—and very easy to work with. There are some obvious refactorings that I noticed, and that Walter mentioned, like generating some of the callbacks, etc. dynamically. I might take a whack at that sometime.

As for the workshop day, it was much less hectic. In fact, there were a couple of hours with not a lot to do. I think the group was waiting for some guidance from Mel and Walter and they were busy in IRC with some Sugar and SoaS issues. I wish we had known that and I probably would have gone and tried to focus on something interesting or at least gotten my release of WPI Suite built.

The project for the next couple of days

Jerry Breecher and I are going to look at getting some tests done for the Activity selected for the group. Right now, it’s not clear whether it will be the Measure Activity or the Sets Activity. If Walter gets Measure to the point it can run by tomorrow that will be it. In either case, it doesn’t look like there’s much of a standard for testing so it should be fun to take a whack at it. The goal is to have a good set of smoke tests that can give an indication of the Activity’s readiness. We’ll look at some existing tests from some of the modules and emulate them or try to do better (something like PyUnit maybe).

POSSE Day 1: Now I know what my students feel like

In OpenSource on June 8, 2010 at 1:17 am

After the first day of POSSE I know how my students feel when I hit them with everything at the beginning of the software engineering courses. This immersion is great. In some ways, it’s utter chaos, but one begins to feel somewhat comfortable by the end of the day with some of the tools. I think that getting Fedora set up in VirtualBox was the most frustrating for me. I didn’t quite get it right this morning and was behind for most of the day I finally got that tonight. This video on YouTube helped a lot.

What was frustrating—too many accounts needed to be set up. A single login for all of them would work really well. That’s the only thing that got me frustrated.

It was kind of cool getting to use some of the tools that I haven’t used before. I’ve never used it before. I’m not sure I like it. There’s just too much going on and it seems too easy to miss things that are meant for me. I prefer using IM, but I am willing to bet that there are ways of filtering things in IRC. Hopefully we’ll get to that tomorrow.

I’m looking forward to the actual activity we’ll be working on this week. Even though Python isn’t my favorite language, I think it will be interesting using it on something real and see how things go.

Like my students, I’m suffering from information overload, but I know that it will all come out okay. That’s the alue of experience.