The Importance of Being Agile: A Trivial Process for Software Developers

I could not resist paraphrasing Oscar Wilde regarding Agile software development.  I’ve been pondering for some time how to properly incorporate Agile in my “software development belief system,” and recently came across the following quote:

The morale effects are startling. Enthusiasm jumps when there is a running system, even a simple one. Efforts redouble when the first picture from a new graphics software system appears on the screen, even if it is only a rectangle. One always has, at every stage in the process, a working system. I find that teams can grow much more complex entities in four months than they can build.

Try to guess who’s the author without peeking ahead…three, two, one. I’ll spill the beans in the next sentences, but suffice to say that I was expecting a prominent Agile author, perhaps one of the authors of the Agile Manifesto, but no.  The author is Frederick P. Brooks, Jr., author of the The Mythical Man-Month, a book written in 1978!

The problem that I had with Agile is that for the longest time I considered it a work in progress. In the 1990’s all the rave was OOP, and then OOD and OOA, followed by the different notations that culminated with the UML.  Back then, as a developer you were considered progressive if you knew objects.  Objects were fashionable, chic, cool.  Structured programming was old, boring, heavy. New systems were developed using RAD’s, Rational made millions selling UML tools, Java took center stage, development processes that used OOA/OOD/OOP and UML with use cases were in high demand.

Then in the new millenium came the Agile Manifesto.  I became aware of the Manifesto early on, and in the following years, as developers came and went, I started hearing stories of success.  Every time I asked, however, I did not get a full picture.  Perhaps because I was asking the wrong questions, or perhaps because I considered that several of the authors of the Agile Manifesto were “jumping ship” after contributing heavily to UML…I was expecting that they would commit to a software development process that would favor UML, but that did not happen.

My “breakthrough,” if I can call it that, came late in 2009, when I was involved in a project long enough (ten months) to try new techniques and with the right team size, a known scope and domain expertise.  We applied only an Agile wall and concepts from Theory Of Constraints, but boy, did it make a difference.  One of the highlights of that project was “on time and on budget.”  Very little overtime from the beginning, since I requested that no one would work overtime for the duration of the project. The project made use of…use cases and UML, not epics or user stories.

After that, I got the “itch,” but got formally involved in a real Agile project until recently, and I’m coming to appreciate the results.  It’s still too early to see the real impact for using Agile, but the results are promising.  Suddenly, being Agile is fashionable, chic, cool, and using UML and use cases is old, boring, heavy. Sounds familiar?

I believe that Agile is not panacea and it cannot solve all the problems.  For one, the company organizational structure plays a significant role in the success of the project(s)–e.g., organizing with functional managers, strong matrix or independent projects.  Another one is the never-ending need for people, and often times teams are short on proper product owners or Scrum masters. Yet another one is the commitment from upper management in Agile, and changing the way software is measured for success (e.g., throughput accounting). Saying that, there are multiple benefits to have focused, geo-located teams working together as one entity towards a single goal.

I also believe that UML and use cases contribute greatly to a system design when properly managed.  A frequent problem with use cases is how to properly write them. After more than ten years of information on the subject, you still find UML artifacts and use cases that are poorly written.

Agile is still a work in progress, but to where?  Eli Goldratt, author of The Goal and Critical Chain, provides some insight.  Summarizing from Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results, all sciences evolve from classification to correlation, to effect-cause-effect.

Agile methods have agreed on internal nomenclature (e.g., epics, user stories, backlog), therefore they have reached the classification stage.

Agile methods , individually, have reached the correlation stage by pattern recognition: techniques such as XP, Scrum, work.

Agile methods, however, have not reached the effect-cause-effect stage. I don’t think that this stage will be reached soon–perhaps by the end of this decade–, mainly because it involves measuring and agreeing on what needs to be measured, as well as the interdependencies among those measurements in order to predict the effect a given decision will have on the project.

This does not take any merit away from Agile methods.  On the contrary, the positive effects from the results is a great motivator to reach the last stage and turn Agile methods into a science.

Now let’s go back and be Agile.

Posted in software | Tagged , , , , | Leave a comment

Installing Windows To Go on a USB 2.0/3.0 Flash Drive or Hard Drive from Windows 7

If you have a spare USB 2.0/30 flash drive or hard drive and want to re-purpose it for Windows To Go, you can follow the instructions at  The guide works as advertised as long as you’re installing from Windows 8.  However, if you’re installing Windows To Go from Windows 7, running the last step will not configure the boot record:

bcdboot.exe h:\windows /s h: /f ALL

The reason is that the version of bcdboot in Windows 7 does not support the same options (in particular the /f option) as the version in Windows 8.

Wait a second…don’t I have Windows 8 already loaded on the USB flash drive/hard drive?  Yes, and you can copy the right version of bcdboot.exe to your Windows 7 machine or execute it in place. The right version can be found at:


where h is your USB flash drive/hard drive letter.

Posted in windows 8, Windows To Go | Tagged , , , | 2 Comments

Installing Windows 8 Developer Preview on an Acer Aspire 1420p

The Acer Aspire 1420p is a nice candidate for the Windows 8 Developer Preview because it has a touch screen with two touch points. If you’re the lucky owner of one from the Microsoft PDC 2009, Windows 8 installs just fine.  I used the flash drive from the BUILD conference as the boot drive, which installs the Windows Developer Preview with Apps  and Tools (x64 version), which should suffice for most installations. If you want to install a 32-bit version, create a bootable flash drive using the instructions at the hyperlink below.  Notice that the 32-bit version fits on a 4GB flash drive, unlike the 64-bit version.

The only trick to the 1420p is that it can boot from any of the two USB ports. The boot options for flash drives are listed FDD at the end of boot list when you enter the BIOS (pressing F2 during the startup sequence).  I recommend to move both FDD options to the top of the list (pressing F6).

After that, you can follow the instructions on

I shrank the Windows 7 Ultimate partition and gave Windows 8 64 GB of space.  Once the installation completes, the touch screen works fine but there are physical limitations to use the gestures that are possible on the Samsung tablet provided at the BUILD conference.  Any of the gestures that are executed by swiping your finger from any of the edges of the screen into the screen (charms: swipe from the left; switch apps: swipe from the right; app bar: swipe from the bottom; bring up options for an app: swipe from the top) are very difficult due to the limited space between the edge of the touch screen and its frame (about 1/4 inch).  You can resort to using keyboard shortcuts ( or use the stylus included with the 1420p. Even with the stylus, the swipe-from-the-top and swipe-from-the-left gestures are somewhat troublesome.

The gesture to switch between applications (swipe-from-the-left) can also be performed with the mouse: let the mouse pointer rest on the left side of the screen for about one second and a little window appears that lets you select the next application.

Posted in windows 8 | Tagged , | 1 Comment

Hello world!

In September of 1988 I was holding a copy of K&R’s The C Programming Language and tried to understand the first C program, the original Hello World. C looked alien to me.

Fortran had been my first programming language in college. The school had a PDP-11 or some DEC machine that had been donated to the school by Digital Equipment, and we used it to compile our assignments.  We had to schedule time in the lab, and that’s where I had my first experience in “concurrent programming.”  The compiler (called the TKB, an acronym that I was never interested in knowing what it meant) was not multi-user, so every time you wanted to compile your program, you’d literally had to stand on your chair and yell “I’m going to use the TKB.” That would be the signal for other users to wait before submitting. Once the compiler was done you would “unlock” the TKB by yelling again and life was good…except when someone wanted to mess up your work and would submit the job simultaneously. There was no “event log” that would say who the offender was, so you would just curse and move on.

Back to C. After college I had enrolled in a class and at the end we had to deliver an implementation of Tic Tac Toe.  Having been an avid chess player during high school, I was excited to come up with the magic formula that would evaluate the position and perused through some books that had something on game theory and stumbled on what looked like a good algorithm for the game. The instructor had given us loose instructions on the user interface, but he preferred a GUI.

Having no time and no money, only a copy of Turbo C, and not willing to invest time in a GUI that came in one of the C books from Herb Schildt due to several bugs I had to solve for it on another project, I decided to tackle the project using the algorithm, but alas, there was a problem position where the evaluation function would fail and the computer would lose.  So I injected a “special case” to make sure that the function would safely make it should it encounter the losing position.

At the end of the project, the other two teams got a beautiful user interface–and both teams used Pascal and not C–but my ugly baby with a command-line interface, writing O and X and asking for the coordinates of the next move, was the only one that would not lose.

I did not get the best grade, though.

Posted in concurrent programming, software | 1 Comment