Just sharing some of my inconsequential lunch conversations with you... RSS  

Tuesday, October 31, 2006

In the defense of the blogosphere

I'm collecting a series of arguments in the defense of the blogosphere, which I'll post when completed. After receiving an email from a friend, I got this new one, by replying:

"Help stopping spam - post a blog"

REF: The Single Most Important Virtual Machine Performance Tip

If you use virtual machines at all, you should have the single most important virtual machine performance tip committed to heart by now: always run your virtual machines from a separate physical hard drive:

[the] biggest performance win is to put the virtual hard disks on separate disk spindles from the operating system. The biggest performance hit in virtual machines is disk I/O. Making the VM fight with your OS and swap disk makes this issue much, much worse. Additionally, today's USB 2.0 and firewire external hard drives run on a fast interface bus, have large buffers and spin at 7,200 rpm, as opposed to 4,200 rpm for most laptop hard drives.


That's one reason why all the desktop machines I build now have two hard drives:

  1. A faster, smaller drive for the operating system and essential applications. You can't beat the 10,000 rpm Western Digital Raptor series for this role.
  2. A larger data drive for virtual machines and everything else.

in: Coding Horror.

Monday, October 30, 2006

Microsoft Virtual Lab Express: Team System Overview

We no longer have an excuse not to try new products. Remote access to virtual machines is the perfect way to try out new technology. Here's how Microsoft is showing their goodies:

By offering remote access to a virtual server machine, Microsoft Virtual Labs allows you to test the products without installing nothing in your system. Ok, you'll have to install virtual server remote console, but that's pretty much all you have to try out a fully configured system.

For a taste of it, please try the Microsoft Virtual Lab Express: What's new in Visual Studio Team System.

In this lab you will learn to:

  • Create an application
  • Create unit tests
  • Determine and enable code coverage testing
I hope other vendors will follow this path - I usually install demos in my local virtual machines, but still they need to be configured. This is the way to do it!

Saturday, October 28, 2006

To MVC or not to MVC?

Back in the old days, when I worked on windows desktop applications, I did a lot of programming with OWL and MFC (ok, after my pre-petzoldian and petzoldian periods, so I'm that old!). On those days, both class libraries supported MFC implementations (probably not as isolated as possible, but for the sake of this article, MVCs).

On those days, we called that implementation Doc/View. And after they arrived, managing MDI MFC applications without CDocument and CView was no longer an option. And imagine implementing an OLE2 compliant application on OWL (in my case, it was a workflow editor) without TOleView. Doc/View was a earned right, and we don't easialy give up earned rights...

Then came the internet, and my cosy programming world was turned upside down. So I did some CGI applications in good old C and C++ (I should probably have chosen Perl, but I have this thing about scripting...), and throw away my good old MVCs.

Then came ASP. For most that I hated the VB idiom and limitations, it made all the difference. I was still miles away from my MVC (man, I even lost most of my OO goodies), but things were getting better.

Then came .NET, and I understood what Moses must have felt when leaving the desert! I had most of my good old OO goodies back! And something that was less an MVC than the old MFC implementation, but that worked like a charm!

This paradigm was a simple, very well tested and proven model used in successful developing environments. It had it roots in great developing environments like Turbo Pascal and Turbo C, later refined in Turbo Pascal for Windows, Visual C++, Visual Basic and C++ Builder. But the MVC is still missing...

The question any ASP.NET architect is asking is: how (and when) to implement an MVC? First, let me point what I feel lacking in the present model:

  • Firstly, the model just doesn't exist. Well, at least it isn't enforced, most programmers do represent it, but the articulation with the View and Controller is weak and optional.
  • Then, the controller logic is hardly reusable.
  • Finally, the presentation logic is untestable. Well, this remains a MVC limitation - the MVP pattern handles this problem.
So what is the solution? Microsoft p&p answer is MVPC (Model-View-Presenter with Controller) is the way to do it. From WCSF documentation:

Separate the responsibilities for the visual display and the event handling behavior into different classes, the view and the presenter. The view class (the Web page) manages the controls on the page, and it forwards events to a presenter class. The presenter contains the logic to respond to the events, and in turn, manipulates the state of the view. The presenter class uses the model (frequently, this is application state that is represented by business entitles) to determine how to respond to the events.

The presenter manipulates the view when the model changes and it updates the model as the user interacts with the view. To retrieve and update the model, the presenter interacts with domain business logic. The domain logic should be the same for all types of presenters. (The presenter can call the domain but not vice-versa.) To achieve this, you create a controller. The controller interacts with data sources (for example, through a data access layer) and contains presentation-independent business logic (for example, workflow.)

For much that I agree, I know that most people will consider it an overkill. And for most simple projects, it will be.

One thing's for sure: until MVC (or MVPC) is supported out-of-the-box in Visual Studio, the majority of people probably won't use it.

Microsoft Visual Studio 2005 IDE Enhancements

Not what I would call a must have extension, but a powertoy is a powertoy and we geeks cannot resist a free development powertoy, can we?

Visual Studio 2005 IDE Enhancements are a set of Visual Studio extensions that are designed to make you more productive. These enhancements are directly integrated into the Visual Studio IDE. This set of enhancements includes Source Code Outliner, Visual C++ Code Snippets, Indexed Find, Super Diff and Event Toaster tools. All these tools except the IDE Event Toaster can be invoked from Visual Studio’s View.OtherWindows menu group. The Event Toaster tool can be configured from the Tools Options dialog under the PowerToys node. The Visual C++ Code Snippets can be invoked on any C++ source file. Previously, these enhancements were only available via the Visual Studio 2005 SDK. This installation does not require Visual Studio 2005 SDK.

  • Source Code Outliner : The Source Outliner tool is a Visual Studio extension that provides a tree view of your source code's types and members and lets you quickly navigate to them inside the editor.
  • Visual C++ Code Snippets:The Visual C++ Code Snippets tool lets you insert snippets in your code by using a pop-up menu that contains programming keywords. VB.NET and C# languages have this functionality in Visual Studio 2005.
  • Indexed Find : The Indexed Find tool is a Visual Studio extension that uses the Microsoft Indexing Service to provide improved Search capabilities to the integrated development environment (IDE). It sends the results of a search to the Output Window.
  • Super Diff Utility: The Super Diff Find tool is a Visual Studio extension that compares text files. It uses color coding and graphics to show the difference between the files in deleted text (red), changed text (blue), inserted text (green).
  • Event Toaster Utility: The Event Toaster tool is a Visual Studio extension that notifies users about specific events within the Visual Studio IDE.

Friday, October 27, 2006

Using the right version of MSXML in Internet Explorer

I came across this article about MSXML compatibility issues. It presents the why and how of MSXML usage. Now that Ajax is on the ramp-up, the correct instantiation of MSXML can be critical.

And this will be particularly important on IE7, that no longer supports MSXML4 and 5 (without user approval).

It's a pity that MSXML didn't deserve the same treatment has XmlHttpRequest - integrated out of ActiveX scope, and into de facto standart. Will this ever happen?

Thursday, October 26, 2006

Macros and templates

One of the most disappointing experience I had with Visual Studio 1.51 was the absence of template support.

I wasn't used to work without templates anymore. Even worse, I was porting Borland's code that depended heavily on templates. So I used macros. It worked like this:

I defined a macro for the class instantiation (the parameter being the class), and another one for class usage. The templates them selfs ended up easy to port. The code wasn't so nice to read, but it worked.

One of the features I lacked more from my C++ times was template support. It's strange having to wait for so long for generics to re-enter the scenes...

Makefiles in Borland C++ 3.1?

Back in the early 90s, I was working on a product built in Borland C++ 3.1

Working on a project was quite simple, but building a version was a nightmare: Borland had forgotten to give us a make utility for their projects, so we had to open the .prj one by one, in the right order, build it and collect the results. Well, to be true, Borland had a make utility, but it didn't accept .prj files - it only converted them into makefiles loosing some properties.

As the product grow larger, so did the daily build process. Having to build over 20 libraries and 8 to 10 applications was not a nice way to end a day. So a nice little utility was born: bccc - I named it over bcc (Borland C Compiler).

bccc would take by argument a project, open it with Borland GUI, send the WM_COMMAND messages that issued a build operation (simulating the key presses), wait for the result (monitoring the appearance of a close button, if memory serves me well), collect the results peeking from the GUI result listbox, and issued a WM_QUIT to exit the application.

We could now produce our make file. It was a command file with a bunch of bccc commands, one for each project.

It wasn't much, but that what we had back then :)

RoboCopy goes GUI!

RoboCopy stands for Robust File and Folder Copy. For some strange reason, Microsoft still deploys the unreliable copy utilities with Windows, and hides the reliable ones as extras in the Resource Kits.

For years we've been using robocopy as a console application. We can now use the GUI version.

Tuesday, October 24, 2006

REF: What if ASP.NET controls could actually generate CSS friendly markup?

in: ASP.NET Friendly CSS Controls

ASP.NET is a great technology for building web sites but it would be even better if it provided more flexibility for customizing the rendered HTML. For example, the Menu control makes it simple to add a menu to a web site, but it would be better if it didn't create tags and was easier to style using CSS. Happily, it's easy to customize and adapt the Menu control to generate better HTML. Indeed, you can modify any ASP.NET control so it produces exactly the HTML you want. The key is to use something that may be new to you: control adapters. These are little chunks of logic that you add to your web site to effectively "adapt" an ASP.NET control to render the HTML you prefer. The CSS Friendly ASP.NET 2.0 Control Adapters provides pre-built control adapters that you can easily use to generate CSS friendly markup from some of the more commonly used ASP.NET controls.

Monday, October 23, 2006

Am I Media (des)center(ed)?

I've been crying for year for a media center that I still can't find. So what am I looking for?

I'd like to have a media center in my living room (well, throughout the house would be nice), in which I could access a DVD juke box. That's all. Is it that much to ask?

Ok, let ask for a little more: for a start, the DVD juke box should be scalable (I'd start with something like 500 DVD).

Next, the jukebox should be kept outside the living area - something like the garage, or the attic.

Then, the media center should have index capabilities, and the ability to cache most recently/used fragments.

This appliance should play all kind of media formats, and naturally be upgradeable. And it would have the capability to read PDFs and Open Document formats. And still be capable of connecting to other intranet and internet stores, as most media centers do.

Did I mention it should be wireless? And that It should have authentication / authorization mechanisms? And secure transmission?

Am I asking too much? Ok, I'll throw away a feature: it doesn't have to connect to iPod :)

Oracle releases 11g database beta

So Oracle is releasing 11g's beta.

I haven't tried it yet, but for what I can see for now, and apart for the compression (and performance) technology, it all comes down to datawarehousing and applicational enhancements.

Was I expecting too much? Is the evolution of the database core functionalities loosing steam?

Read the full article at RegDeveloper:

Please leave this line here

When I started working, I came across the following C code on the application I was maintaining:

// don't uncomment the next line
// strangely, it prevents a crash

sprintf (buffer, "");

I discussed that line with my team leader, that explained me that the application had been experiencing heap and stack corruptions here and there, and when adding debug, he found out that a simple (later simplified into an empty) sprintf would solve the problem.

My first thought was: "What kind of demented and irresponsible team leader would kept this without identifying the source of the problem?". The answer came with time: a pragmatical one. The application run years and years with the memory corruption, and the healing patch, and was finally terminated when the business it supported ended.

Don't get me wrong: I think that we should do whatever within our power to keep control over our applications. I still think his attitude was somehow reckless. But there are times when the proof of time defies the logic of the mind.

Thank god for garbage collectors...

Friday, October 20, 2006

Virtual Machine History & Technology

I was catching up some old podcast of Security Now when I came across this great article: Virtual Machine History & Technology.

Here's the description:

"Steve and Leo discuss the historical beginnings of Virtual Machine technology, from the 40-year-old IBM VM/360 operating system through virtual machine language emulators and today's VMware and Virtual PC solutions. This kicks off a multi-episode discussion of the tremendous security benefits and practical uses of modern day Virtual Machine technology."

Besides the VM technology itself, some oldies they refer to:

  • real mode to protected mode evolution
  • 8086/80286/80386 evolution
  • EMM386, Quarterdeck Expanded Memory Manager (remember the need to load drivers into high mem?)
  • DESQView, DESKView/X and Windows 3
  • Native versus P-Code discussion
  • Writing directly to video memory at B000 or B800
  • Borland's Turbo Pascal
And much more. Please don't miss it:

High quality (64 kbps) mp3 audio
Quarter size (16 kbps) mp3 audio

TechEd's shop list

TechEd: Developers

Preparing the sessions to attend at TechEd is like writing you Christmas wish list: there's so much to ask for, and such a short list to write...

So here's my strategy. My priorities goes to:

  • Architectures in general (so I'm like George Constanza, so what?)
  • LINQ
  • some of WF and WCF
Even with this headings, I'll still be missing a lot of incredible sessions...

Thursday, October 19, 2006

Interesting topology

Until finally surrendered to low energy router / firewall appliances, I used to have a linux box has my first layer of protection (Mandrake SNF, MNF, Astaro, or just the ordinary linux server with Shorewall). I'm talking about my home topology, and, needless to say, I have nothing to protect back home that justifies such heavy armoury, but this is the kind of things that distinguish business man from geeks, so I couldn't help it.

It was I Pentium I, running at 100MHz, with 32 MB of memory and 1.1 GB of disk. But man, was it noisy...

So one fine day, like 2 years ago, I asked my self: "Why isn't the firewall running inside a virtual machine?".

I didn't think twice:

  1. Shutdown the firewall and a virtual machine host server.
  2. Move both network cards from the first to the latter.
  3. Installed a router firewall (IPCop, a simple to install firewall/router was all I needed for my proof-of-concept). I kept the original firewall configuration information, so that the change would be transparent.
  4. Hooked my WAN cable to the external interface on the router / firewall.
  5. Hooked a cross-cable between internal interface and the host network card.
  6. Did some tweaking with the VMWare Network Configuration.
And that's all! I was running on a computer who's router/firewall was donated by his own virtual machine guest! Did some performance tests, and found no performance loss.

So I kept it running for a month or so, where it was finally replaced by the low energy appliance I'm using until today. The reason of the replacement was simple: I needed to recover memory on the virtual server host to create a new virtual machine...

It was an interesting proof-of-concept. From the security point of view, it was nearly just as secure as the solution it replaced. From ecological and maintenance view, it was by far a better solution.

Wednesday, October 18, 2006

Reviewing a review

I've just read Joel Spolsky's review on "Beyond Java".

First, I'd like to point out that being slow to adopt new technology is a dangerous think to do in our line of busy, no matter how old we are. I'm 36, and I love adopting exciting new programming languages, whenever I see fit.

That doesn't mean I'm on an adoption mood toward typeless dynamic typing languages. Maybe because of the way I was educated, or based on my experience, I think today's typeless dynamic typing languages give us more problems that the ones they solve.

In a much smaller scale than Joel refers to, lets imagine a developer with the following experience:

  • developing in Visual Basic
  • developing in C / C++
  • developing in ASP
  • developing in ASP.NET
  • developing in Ruby / Phyton
This developer experience is not an evolution toward typeless dynamic typing languages. In each step he turned on typed static typing mode, to turn it off on the next step, and so on.

As I stated earlier, the present advantages of typed static typing languages surpass the advantages of the typeless dynamic typing ones. Why? Because the single fact of knowing the type in advance closes the scope of the operations, and that is a simple and cosy way to work. Ok, the scope limitation also limits the system capability, but so what? Most of us as developers live happily with it.

Lets end giving Joel a hand. One thing is for sure: the systems we develop are but rough representations of real life systems. And in real life, we aren't forced to declare the type of the entities to interact with them - they are (generally) implicitly retrieved by their nature...

Post-editing note: my thanks to André for the naming corrections present in his comment.

Tuesday, October 17, 2006

Project Management Certification

I'm presently in the process of certification in Project Management .

The certification authority is APOGEP, a member of International Project Management Association (IPMA).

I've been managing projects for some years now, so I thought there was nothing much to learn. I was wrong. In the course I've been attending to support the certification, I've been absorbing much formal structuralism that I lacked, and that will help me improving my management skills.

APOGEP certifies four different stages of program certification:

Level A: Certificated Program Director

Must have capacity to guide all projects that form a program or all projects from a business unit.

15 years of experience as project manager where the last five were passed as project management director, with a direct relationship to customers and employees.

Level B: Certificated Project Manager

Must have capacity to guide all projects that form a program or all projects from a business unit.

10 years of comproved experience as senior coordinator technician in project teams and/or as project manager, where the last five were passed as manager of complex projects.

Level C: Certificated Project Management Professional

Is capable to manage small projects, coordinate technical tasks and to support project manager director activities.

5 years of comproved experience as senior coordinator technician in project teams and/or as project manager within small projects.
Certification exam approval.

Level D: Project Management Practitioner

Must have knowledgment on project management that can be applied in specific areas. Experience is not required.

Certification exam approval.

I presently hold the lower of the certifications - Level D. It's like being certified to be a wizard's apprentice.

I'm working toward the next Level, Level C. I just produced a report of my management experience, and I will be put to trial on an all day project management workshop - I'm expecting an urban guerrilla warfare kind of workshop. It wouldn't be nice, I've been informed...

Why do projects fail?

Let's start with a definition of project success criteria:

  • It is delivered on time.
  • It is on or under budget.
  • The system works as required
Only a few projects achieve all three. Many of them aren't even used!

Why does this happen? The reasons commonly pointed could be:
  • Lack of top management support
  • Lack of User Involvement
  • Inadequately trained and/or inexperienced project managers
  • Failure to set and manage expectations
  • Failure to adequately identify, document and track requirements
  • Poor plans and planning processes
  • Poor effort estimation
  • Scope Creep
  • Cultural and ethical misalignment
  • Misalignment between the project team and the business or other organization it serves
  • Inadequate or misused methods
  • Inadequate communication, including progress tracking and reporting
  • Poor leadership at any and all levels
  • Long or Unrealistic Time Scales
  • No Change Control System
  • Poor Testing
This are all organizational problems, not technical ones. But they too have their contribution:
  • Lack of development methodology
  • Weak technical leadership
  • Difficulty in sharing among pairs (particularly problematic when passing information to newcomers)
I found this old paper, where it lists top 10 ways to guarantee the failure of a systems project:
  1. Don’t use a specific methodology because coding is all that is really important
  2. Create the project plan by working backwards from a drop-dead system completion date
  3. Don’t bother with a data model [editor: I'd had to had Domain Model]. Just build whatever tables [static structure] you need.
  4. Use a Technical Lead that has never built a similar system. Hiring such talent is too expensive.
  5. Hire forty developers to make the coding go faster
  6. Build the system in Java, even though most of the development team still thinks that Java is coffee and you have no intention of ever deploying to the Web
  7. Three months before the system goes live, assign one junior developer to handle the data migration
  8. Skip the testing phase because the project is way behind schedule
  9. Change the system to support critical new requirements discovered during final development
  10. Buy a commercial, off-the-shelf package and customize it … a lot [editor: sorry, it was true in the past, but not necessarily in the future...]
The paper ends with the following recommendations:
  1. Don’t cut corners, methodologically. In the long run, this results in system failure or an inadequate system that doesn’t meet the users’ needs.
  2. Audit each major deliverable and step along the way for accuracy and correctness.
  3. Carefully monitor top management support for the project. Make sure that managers are aware of the progress of the team.
  4. Secure the correct technical lead for the project.

Monday, October 16, 2006

Not invented here syndrome

Raise your hands who hasn't seen the not invented here syndrome in action? Anyone? I though so.

Let me tell you a story about an old friend and colleague of mine that had no match in this syndrome. If you're reading this post on my blog, I got his permission to post.

Back in the early 90s, we were developing an office automation product where we built, among others, a Windows client. The client was written in Borland C++ 3.1, and we had the first experience of building a library that supported several applications.

My friend, let's call him 'Mister F', was one of the most brilliant engineers at the enterprise. One of the things that I learned from him was the concept we now call refactoring. Ok, 'Mister F' did refactor with no consideration whatsoever with the rest of the team, or even the product's milestones, but nevertheless, he did refactor, that was more than most of us did back then!

He was mister "Not invented here syndrome" in many aspects. The idea of starting a library was his, so he simply suffixed his initials in the bloody library! We all used and contributed for the library for a decade, and the library was never renamed!

Let me give you another example: in the early days, I extended Borland's TListbox with the ability of drawing an icon left to the text, using the owner draw mechanism. I called it TStampedListbox.

Some time later, 'Mister F' felt the need to have a listbox with multiple columns. So did 'Mister F' extend TStampedListbox? Of course not: he just created a new class, in focus with his ego: TSuperListbox! I was mad as hell, I confess. Why didn't he reuse my code?! Would there be Council of Trent in the library? Not a very good idea, so I gave up my listbox, and ported my applications to TSuperListbox.

But that's not all. One fine day I felt the need to add new functionality to TSuperListbox, but 'Mister F' actively refuse to change or let me change 'his' listbox, as any change would subvert the philosophy of the holy listbox! So what now, I asked? "Do your own listbox", he replied. And so I did.

After some fights with 'Mister F', I manage to convince him to do some minor changes on his class (mainly exposing some data and functions) that allowed me to derive my listbox from his, adding new capabilities. I was angry, so I made a statement, naming it THyperListbox.

In each year that passed, and for each child he had, we all witness his growth as a member of a team, loosing this symptoms of the NIH syndrome.

We no longer work together, but whenever I sense the presence of any of these symptoms in a team member, I recall 'Mister F' story, and hope for the best.

REF: Automating Software Development

Automation Software Development is an very dear subject to me. Yesterday I listen to an extraordinary ARCast, where Ron Jacobs and Martin Grannel explained perfectly the need for automation in software development.

Better than whatever clumsy synopsis I could do, please listen to Automating Software Development.

PS: an interesting definition Martin introduced to me was the "Not Invented Here Syndrome". I'll be back with this in the near future.

Sunday, October 15, 2006

REF: Ditch the tie, Japan tells workers as "Cool Biz" drive begins

A friend of mine just email me this link: Ditch the tie. Japan is ditching the tie! Finally someone listens!

I'm Portuguese, and here we have the strange habit of using ties - even people that sell door to door wear ties here!

I can understand using ties in Germany, but in countries like Portugal wearing a tie in summer is absolutely nuts!

So listen to this example from Japan, and ditch your ties! If you still feel the need to have a more formal look, choose a more ecological one!

Friday, October 13, 2006

To ORM or not to ORM

1. Yes, it is true: code generated object relational mapping is not straightforward.

2. Yes, it is true: for now, scability can only be totally guaranteed by handcrafted coding.

I'm sure the first question was put during the industrialization era, and well put, I must say: for sometime we, like they did back in the 19th century, will not know when to handcraft and when to industrialize. The process is not mature enough.

As to the second question, I believe that we can use the 80-20 rule for many of our projects.

Will we be better served with the tailored version? Hell, yes, but it will cost us a lot more!

Let me give you an example: I'm short and fat, so prait-a-porter is not a good choice for me. But the lucky people that stand near the distribution mean have no problem with the industrialized approach.

My point is: we should weight the earnings that this opportunity can give us against the risk of choosing immature processes, and remember: the industrialization path is sure to be dominant, but we will always have prait-a-porter :)

Thursday, October 12, 2006


A thought on Bet Schwegler's 2 cents motto - "It is not the strongest of the species that survive, nor the most intelligent, but the ones most responsive to change - Charles Darwin".

This motto is just awesome to describe nature and software evolution needs. But I'd had to ask Darwin, if he could be here to answer: "Isn't the ability to change part of the processes that contribute to intelligence itself? In the sense of being capable of solving problems for what we were not specifically prepare to resolve?"

Well, the question is just academic, please don't feel obliged to comment. Nevertheless, it is still a great motto!

Wednesday, October 11, 2006

KISS Principle

Let's talk about simplicity: according to wikipedia, KISS acronym is known to have been in use during the Apollo project in the 1960s. Probably not used to the most - remember the problem of writing on space? Americans spent a lot of money creating a pen that writes on space, Russians simply used pencils...

The some article states: "One of Einstein basic sayings: everything should be made as simple as possible, but no simpler."

Now for the real reason for this post: talking about great definitions, Brad Adams has this awesome principle: "Treat Simplicity as a Feature". Uau...

REF: Why Restaurants aren’t run by the Software Industry

Though it was written in February, I'm still talking about this great article from Beat Schwegler , so I've decided to recover the subject.

The article is: Why Restaurants aren’t run by the Software Industry, and boy, did Beat chose the right way to express the problems we have in our industry (our should I say, our craftsman).

Beat invites us to imagine the experience of a dinner in a restaurant that is run by the methods and principles of software development, in an hilarious scenario that is guaranteed to make you rethink our methodologies.

In the end, he comes with some interesting points that may help our industry to better understand how we can become more efficient:

  • To deliver on the highest level of quality, you need to be specialized. Not only are most restaurants categorized (Thai, seafood) but the smaller the menu, the more likely the ingredients are fresh (freshness increases the quality).
  • To create a dish fast and on the highest level of quality you are required to focus on a small number of dishes. This allows you to think about the streamlining of the preparation and you’re able to prepare the different “building blocks” in advance.
  • To avoid misinterpretation provide your guests with a menu. Also be aware that they might be unknowledgeable of the domain specific expressions such as “Pommes Dauphine”.
  • To deliver on time, planning and preparation is essential. When the chef is planning a new dish, he is not only thinking about the recipe but also about the way he can streamline its creation. What are the “building blocks” that need to be prepared upfront (such as the stock), what is the stuff that will be prepared before the restaurant opens (such as cutting onions or herbs), what are the required tools (e.g. steamer)… For a restaurant, a successful dish doesn’t only require a great recipe but also clear descriptions of the requirements, different building blocks, tools and a process that describes how to cook a meal on a consistent level of quality.
  • Prices are based on a transparent calculation based on the cost for ingredients and the time needed to prepare that dish.
Beat ends the article saying: it’s very promising to see that these points are addressed by the four “pillars” of Software Factories.

Uau, isn't just great when complex problems are made simple to understand?

The truck number problem

Truck number - or truck count - is the number of team members that would need to be hit by a truck to kill the project. It's a concept very dear to the Agile community, that improves this track number by using, among other, the pair programming technique.

For ages that I make use of the concept, not always from a fully formalized perspective, but assuring high track count numbers for the projects where I was involved.

So, if pair programming isn't compatible with your organizational culture, my advise to get higher scores in track count is:

  • Avoid the dependency of layer and core modules to a single member.

Often we depend too much on one member. The problem of track count isn't always definitive. The truck count may be exposed when the guy that build the data tier went to holidays and some urgent bug is discovered.

Please note, I'm not saying team members shouldn't have some specialization, I thing they should. But keep in mind that the rest of the team should have the capability to maintain the application, and to assume control over a truck kill. And for that, the answer is simple to identify and harder to implement: communication...

Sunday, October 08, 2006

My First Posting

Welcome to my blog.

My name is Mário Romano, and I'm in the business of producing bugs since 1992.

Since 1998, reckless people irresponsibly gave me teams to leader and projects to manage, but every now and then I manage to take some time of having fun writing code.

The purpose of this Blog is to share some of my inconsequent lunch conversations with you.

Development Catharsis :: Copyright 2006 Mário Romano