10/13/2006

MOVED!!!!!!!!!

I moved my blog to blogspot, you can find it here. This will remain on-line for a while. Please make sure to update your favorites!

Thank you for the attention.

10/04/2006

I had two managers

I had a number of bosses in my working life. I reported to various people, some good and some bad, but I can consider myself quite an expert on being managed.

Today, I want to talk about two of them, the two best bosses I’ve ever had.

The first one was also my first boss. As a young developer, I worked at a global consulting firm. My team’s coordinator was the most productive developer I’ve always known. He was able to write pages and pages of code without a single bug. I’ve heard of Mozart writing music without corrections ever, he was the Visual Basic equivalent of Mozart. He was also bold, good-looking and very, very clever.

I implemented forms and procedures interlocked with the backbone that he created in previous projects. More often than not he used to write down a bit of pseudocode and let me connect the dots. In few months, I was able to do a lot by myself (usually I learn quickly) without hints. I also learnt very well the large system we were developing for an even larger firm. Given the high turnover, that will ride me down later, I quickly become the maximum expert on the system. Despite that, he used to discuss with me even the subtlest details of the implementations, improving my ideas. He had an insight that I was barely starting to parallel one year later.

The second one was the CIO of the Italian subsidiary of a large French multinational firm. By that time, I already had several years of experience but I did not make to be a project leader yet. I had quite a large expertise on Business Intelligence and planning on Microsoft technologies. I was, for the large part of the tasks, independent.

My boss, at that time used to give me a target, a budget, and then let me go my way. Sometimes we used to sync about the projects, usually at the coffee machine. When I needed help or I had something significant to tell, we interacted; otherwise there was no need. I enjoyed the largest freedom ever. That was the time when I learnt the most, improved my skills at the fastest pace and reached the highest responsibilities available in the company. In fact I experienced a row of positive outcomes.

They were both good bosses, but they could not have been more different. The first micromanaged me, he did what usually is thought to be a bad practice. The second, on the contrary was the prototype of the good manager (maybe it was because of the management courses…).

How comes I loved both? How comes I loved the first one?

Because the first was a person I could admire and learn from. He was the single person who contributed the most to my professional education. This means that micro management and detailed resource coordination are not always wrong. People with no or little experience actually need micromanagement. Micromanagement is what can take them out of their whiteboard condition. There are a number of bloggers who support my second boss’ principles, and there is a general agreement around them. I myself agree (after more than ten years experience, I too hate to be micromanaged), but let’s not forget that young people can become effective and experienced by managers’ constant care. Note that I say care opposing it to scare, which, in turn, is the most common method to manage young people forcing a Darwinian selection among the youngest.

So, managers, let your stars go ahead alone, and help the young move their steps.

09/25/2006

You can find here a post that exactly summarizes my view on today's world of work.

Albeit based on the rightist French thinker Alexis De Tocqueville observations on the rising American democracy, it clearly states that, without freedom in daily choices, there's no freedom at all as big freedoms do not affect life too much and too deeply.

08/03/2006

I hate *.*

I googled the sentence "I hate windows" and it returned 51.900.000 hits.
Then I googled "I hate linux" and it returned 26.800.000 hits.
Considering that Windows is run by the 90% of the computers on this planet, giving to much more people the chance to rant about it, linux is much more hated than windows, it appears....

:-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-)

07/24/2006

On Open Source Software

Today we host Rick Ellis, CEO of pMachine. He wrote a piece that summarizes what I always thought about OSS. It is definitely worth reading.

http://www.ellislab.com/index.php/open_source_reality_check/

07/21/2006

The Worst Mistake

I recently undergo the worst mistake that can be done in a business intelligence project.
Of the large number of pitfalls there is one that must be avoided at all costs.
It spoils developers’ and consultants’ lives, it makes the client terribly unhappy and helpless, it automatically makes the project go late.
So never, never, never, never, never, never, never…

…build a business intelligence system (or a part of it) before the source system is fully deployed.

It is such obvious evidence that it should not be necessary to explain this further, but I keep seeing projects where the main transactional system starts together with the BI system. Along with this I keep seeing stressed consultants and disappointed customers.
So, what are, once and for all, the reasons that prevent a BI system from going live right together with its transactional source?

If there’s no data to analyze there’s no way to analyze them.
It seems too obvious but a system with only a handful of test data is not representative at all of the entire cruising situation.

Migrated/Imported data are not suited for developing.
Maybe the new system is filled with migrated data. They are not suited for BI development as well. They are not because, often, systems work well with different patterns that are not the patterns produced by the operational system itself. That is, some test data fields may be filled while, in new transactions after go live, they’ll be empty, or will contain a different value. Some lookups may work only before, on migrated data and not after. Some phenomena may actually take place only after the go live. To build a consistent ETL process, to cleanse and rearrange data, all the data patterns and all the phenomena must be in place. Each early try is doomed to failure as unnecessary transformations will be put in place and necessary ones will be left.

Business Intelligence is related to bulk data analysis.
 Business Intelligence queries normally sweep large amount of data to extract aggregations, averages, metrics of any sort etc. This means that testing those operations on fake data is by no mean a sensible way to develop data. True values can be figured out only from true data.

Many Business Rules are implicit.
 Not all the business rules that are meaningful to the analysis are explicitly stated. Many are embed in the transactional system functioning. Often they are taken for granted by users and ignored in the requirements collection step.  The database builder and the report builder will be called to a detailed work to carefully analyze those rules and transform them to the reporting/dashboard expected behaviour. Usually these rules do not apply to the generality but to particular cases. Test data cannot catch up these cases.

So, I hope you’ll think to this short article the next time you’ll find yourself in an “everything now” situation.

06/23/2006

These days are very busy. An important client has started and, as usual, there is a number of issues to be sorted. To tell the truth, I've been working two week-ends in a row and the coming one looks no different.

The overall situation is not very bad, but I'd like to remind you this book:Death March by Edward Yourdon . It's a clear description of an experience which is traversed, at least once, by each IT professional. The book also states clearly that there's only one real solution: to quit. If your career falls too often in doomed projects that occupy all of your time and suck the energy out of you, consider quitting. There is no price for your well being.

06/17/2006

Today we are pleased to host Raj Chaudhuri, who wrote an interesting piece on Windows permissions. It's a technical piece but it's so clear that it is absolutely worth reading.

...remember a few simple rules.

1) Every process in Windows runs as a user. What the process can do is by and large what the user can do. You can find out which process is running as which user by looking at the User Name column of the task list.

2) There are two kinds of permissions in Windows: resource permissions and policies. Resource permissions are associated with resources such as files, directories, printers etc. There are typically several levels of resource permissions, for example Modify, Write and Read on files and directories. Policies are simple rules saying "X can(not) be done" or "X can(not) be done by Y". There are no levels involved in policies. Sometimes, you require policy permissions to be adjusted. Most times, you need to adjust resource permissions, like you are used to doing.

3) IIS is a special-case server application. IIS 6 runs as several processes - each process runs a copy of an executable called w3wp.exe. Each process is called an *application pool*, and can be set up to run as a particular user. When you create web *applications*, you right-click the root directory of the application in IIS manager, and choose which application pool this application will run under. This means that code written in this application will have the same permissions as the user that the application pool runs as. There is one more factor, though: Impersonation. Web applications that have Basic or Integrated authentication enabled make users log in before they can access the contents. IIS can be configured to Impersonate the user that has logged in, that is, code in the application will run with the same permissions as the user that has logged in. ASP applications impersonate by default. ASP.NET applications do NOT impersonate by default, but can be set up to do so. SharePoint, which is an ASP.NET application, is set up to impersonate.

Similar rules apply to other software such as SQL Server. Database Roles are (sort of) resource permissions, because they are associated with individual databases. Server Roles work like policies, because they specify what can or can't be done by a particular user.

As for where you can find help, this information is all there in official documentation. Unfortunately, it's scattered....

06/12/2006

These guys are really onto something.

www.speechagents.com

I was among the first in Europe to explore the possibility of web and voice synthesys/recognition, in the second half of the 90's and, by that time, technology was not mature.

06/10/2006

There's a debate going on on the Internet on what makes the Silicon Valley so spectacularly productive regarding technical talents.
Paul Graham wrote a couple of interesting articles (Silicon Valley and Startups in America)on the topic. In my opinion they are mostly true, even if Graham views of the labour market is very hard to share.

Guy Kawasaky outlines a number of insightful points.

Joel Kotkin, on the contrary, finds some weak points in Graham's arguments.

What Poldina is interested, though, is wether a Silicon Valley could eventually be reproduced in Europe or not. It is sad to say, but many of the conditions depend to heavily on general US conditions an from the American hearth and soul. This does not mean that we can not do something good even here in the old world...

06/09/2006

Here is a series of articles about intracompany communication.
My point: we should communicate inside the company following a clear protocol.
The third piece is also a nice help-desk story.

Interfaces and Communications - part 1

Interfaces and Communications - part 2

Interfaces and Communications - part 3