Software architect mistakes

I think that to get up in the morning and brew a good cup of coffee is one of the best way to start the day. You know, the heady fragrance that emanates from the machine-pot, it’s delicious. When it’s ready, pour the coffee into a cup, add some sugar, and finally you got it – end of the coffee making process.

Have you ever thought to design a coffee making process with some diagrams, or doing the same with other banal activities such as taking a shower? Of course not.
For other cases less trivial than these, including software project development, a minimal-design work can be quite useful and somewhat needed.
Often questions arise; is an architecture design worth the time and effort invested in it? Well, you may answer this question first: Are there risks in the project that could be minimized by an early design activity?

The more ambitious and challenging the project is, the higher the number of risks, and the more difficult it is to complete successfully.

How to identifying risks. The easiest place to start is with requirements, in whatever form they take, and to look for things that seem difficult to achieve.
Gathering requirements is fundamental for deciding what to do and how. However, sometimes problems arise at this starting point that lead to the ruination of the project. Some assumptions may underestimate this key phase and shake the architect role to its foundations:

1. It’s someone else’ responsibility to do requirements.

Domains drive the architecture choices, not vice-versa. Requirements can create architecture problems. At the very least, you need to assist the business analysts.

2. I learn the domain as I write the code; incrementally.

While prototyping pieces of software is a way for mitigating engineering risks and figuring out the hardest problems, writing code could be a waste of time for analyzing a domain. Rather, it’s very cost-effective to modelling it in advance.

3. The requirements are already fully understood by the stakeholders.

Clear communication is critical between people and the role of a software architect can be a very difficult one when others don’t understand what you do and why.

4. Domains are irrelevant to architecture choice.

Developers may copy an architecture from a past project. Maybe just following the company standard, but ignoring the motivations behind previous choices. They are more likely to be unaware of the qualities required in the current project.

5. I already know the requirements.

At least the documentation should be in your mind, but designers should use models to amplifying their reasoning abilities and unfold not clearly visible aspects that affect their own risks.

Walzing with the Tech crunch

The economic crisis we’re currently going through is teaching some lessons to the Western countries, in particular to the Anglo-Saxons, that our grandparents know pretty much, although it seems we’ve forgotten the past years in this  financial bubble. The debt has several pros: allows building, buying, investing and, when properly managed, might ensure a safe return and a fair growth of the economy. However, the debt has an outstanding bad side: it must be paid back.  It might be postponed, rolled over, shifted to other (more or less conscious) subjects, and its dreadful effects would be identified as bankrupt, credit-crunch, real estate bubble and recession.

With a view to the software applications, a similar observation might be rightful in terms of ‘state of health’, which point to a family of properties that the software should have to be easy changeable, so it could respond quickly to the requirements evolution. A software that doesn’t enjoy good health is the one that has become fossilised to the original architecture, keeping it as is as possible, never revisited in the light of technological innovations and functional updates, but just patched with improvised and unconvincing surgery.

It’s suffering what it could be defined as inability to bear the debt built up over time, but in this case we’re not dealing with financial debt, this is the technical debt. Even though the term ‘technical debt’ sounds strange, it’s related to the financial fellow in many ways, and it is widespread in software development. The saying according to which economy is based on credit (debt) finds support also in the software world.

consultants at workDevelopers who are reading know well what I am talking about. You’re assigned to work in such XYZ firm from next Monday for at least 3 months, and when you’ll start this new task you’ll be instructed about what to do.

The workout mainly consists of implementing new features on top of the customer’s solid rock application, a very remarkable system built some years ago for serving peculiar needs.

So far, it has worked well, the owners said, you may just make it worse than it is now. Later on, you have no choice but to agree with them.

Expanding or changing the set of features without re-factoring looks like seeding a crop without ploughing the land before, if the system’s authors didn’t predict such an amendment. The harvest could be lost, couldn’t it?

You’ll be asked to complete your job updating the old system and keeping the structure as it is, avoiding to break the fragile balance among components. 

Just for you information, consultants were called few months ago for a similar task. They added such a mess into the code that you have to spend most of your time to figure out what they wanted to do than working effectively on new things. Maybe the customer were disappointed by their way to conduct the development and now it’s your turn.

Thus, in addition to the new enhancements, you should fix what your precursors did. 

This subject is hard to handle and quite unpleasant in particular when the customer doesn’t want to hear talking about re-factoring unless it doesn’t delay the delivery, which is almost impossible, so the scheduled task proceeds as expected.

In short, it looks like going for a walk over the broken glasses swearing you won’t be injured.

Using the post’s subject, it looks like getting into debt again for covering the old one, just for adding short term solutions when too many of these have been applied in the past.

Looking back at the past, I’m realising how this kind of intervention is predominant on the amount of works done, that I don’t know how much time I would have to wait unemployed if I wanted to work only into brand new projects…

Sometimes I’d define myself as a debt collector, and I find it uncomfortable as a lawyer or a doctor would feel against a criminal prosecution or a rescue surgery: it’s an exploitation of other’s misfortunes. It might be painful, but we make the customer feel better.

Recruiter advisory: Explicit lyrics

“I’m a people person, very personable. I absolutely insist on enjoying life. Not so task-oriented. Not a work horse. If you’re looking for a Clydesdale I’m probably not your man. Like I don’t live to work, it’s more the other way around. I work to live. Incidentally, what’s your policy on Columbus Day?”

You, Me and Dupree (2006) 

This is the interview every recruiter would want at 17.00 on Fridays, so fast to let you step out soon for the forthcoming weekend, plain and clear in the outcome.  

Usually it’s not so an easy job for the Head Hunter, selecting people and finding the right ones to slot into the pending position might be hard. The challenge would be more difficult when they are seeking to recruit through controversial methods, which hardly could achieve the wished result. As human beings, we have the natural tendency to think that our choices are rational, while we underestimate the effects of the undercurrents that, in a way or the other, affect our decisions.  We believe to be steady inside the boat in the middle of the sea, even if we are at the mercy of the weaves. We are prone to get swayed

Fortunately, the good recruiter studies books deeply and prepare himself in the training workshops to get rid of those diversions, and then finally he can apply scientific methods to his job. Progresses in this field could be checked when they act like CIA agents asking questions as “What will you do when you grow up?”, “When was the last time you were happy?” and again “What are your strengths and weaknesses?” rather than “Tell me about yourself, describe yourself in one word”. But, dear recruiter, I can’t describe myself in one word, unless it’s both hyphenated and a metaphor. 

What comes first, if I’m talking with the interviewer for the job, is that I want to check if his expectations match with mines. I’m talking with you to show my professional skills, not to talk about my passtime hobbies, neither about dance nor motocycles.

All those requests never end to astonish me for their futility, even if those make sense just for HR department, I’m not going to dig into the matter.


Behaviour interview

A much more effective approach is to conduct very structured interviews where the questions are focused on experience, skills and ability rather than vague things.

What recruiters sometimes try to follow is the behaviour interview assertion, which declares that the most accurate predictor of future performance is past performance in similar situations. It would be enough to fright any financial mentor but it finds logical basis for canditates’ evaluation. Perhaps the behaviour of a single man is easier predictable than a stock index. HR specialists claim that with this method of leading interviews, it’s much more difficult to get responses that are untrue to the candidate character, because these should be detailed descriptions of past events, or experiences faced at work.

I agree on the idea that past experiences are indicative on how people react under certain circumstances, but I’d put less emphasis on that, first of all because challenges are always different. Whatever technological issue the company is facing right now, it would be far from any candidate experience, recruiter may figure out something else by the applicant. What someone has done shows the ability to execute; personality is important, intelligence naturally more so, but improvisation remains the key.  Knowledge workers must adapt their knowledge to the situation, but if during the interview the cadidate isn’t projected on a real scenario to show his capabilities and past learned lessons, how the recruiter actually could form an objective opinion?  

I was rarely asked advices or opinions about real technological matters involved on development,  is that the reason the recruiter doesn’t know much about what the new employee is going to resolve?

Maybe sometimes inteviews are not used for hiring people, but just to gather information on cadidates, to create statistics on salaries, skills and to estimate how long does it take to search for a special kind of professional in the market, I guess.


Recruiters may discard people based on salary, of course they can; especially if the point is that the people are interchangeable, low cost and easily replaceable like a natural resource. usually this happen when the target cadidate is junior.

Salary is a complex issue the more senior the target is. Seniors want to discuss the context of the job before they ask about money. Answering the salary question in a phone screen or in an interview before building rapport drop me to the disappointent, as the recruiter is telling me “We want the cheapest on your position”. That’s ok, but do you want to save money before you know what I have to offer? Or, why are you looking for someone senior?

HRs usually match your CV keywords (better know as buzzwords) with their table axis to define your salary box, framing cadidates in a very simple way. Although the salary offer is equals among peers, a fascinanting metric highlights that 5% of programmers are 20x more productive than the other 95%. Now, let me know in your opinion which section of this statistic is firstly discarded.


I don’t see anything wrong with the interview questions with multiple choices, sometimes they are as funny as filling in crosswords, but some other times these questions upset me for I realized I forgot some exponential functions since the school… Damn!

Although it would be helpful to filter out applicants without a basic education, in several years of work I never had concerned about exponential calculus to strike a business requirement. 


What's the bottom printed row of this function?
for(int i=0; i<30; i++){
   System.out.println("line: "+i);
a) line: 29
b) line: 30
c) none of the above


These requests end up by annoying their prospective employees, any company would lose appeal, dropping any willingness to get hired by the company.

This is a newbie question, then the recruiter answered me telling that every technical employee in the firm had filled such a questionnaire. Really? I don’t think any of the experienced programmers I know would waste time crisscrossing questions like that  on a job interview unless they are hopelessly unemployed, and if the hiring manager is looking for an experienced developer, why ask these first-level programming questions? If the recruiter can’t read the resume, why would a hiring manager?

Let’s get Scrum

scrumAt school times the teacher used to quote an important saying:
culture is what remains after we forget the things we studied thorougly.
The concept is charming, but at that time the principle was often adopted to forget things even before they were studied.

The saying is also valid for software development methodologies, where the best practices try to teach us the right path to come up with something really good, shaping a product in the most efficient way and with the highest quality.
The agile methodologies set few general rules, but the result depends on you, your skills and your team of course, not on the methodology.
Scrum doesn’t produce good software products, but if you are smart, it might suggest you some hints helpful to get away with the failure scenario.

What does Scrum say?

It declares that all activities are in a time box and assigns to each team member his own responsibility based on workload estimation, and the activities priority has to be shared with your chief, most of the time the Scrum master.
The daily meetings are essential, the team members explain what they did the day before and what they are going to do today and the blocking problems that affect the task development, as well as the estimated time for the new task or its progress update.
As in the rugby game from which Scrum took its name, the goal is to get things done. The powerpoint presentations, the docs are internal artifacts but the objective is to get product shipped.

How? By setting objectives for the next iteration (sprint), and incrementally so on with the next. The iterations firstly face the most critical issues and the trivial ones come later, as you are mostly concerned with the software/system architecture and you’d know if such solution overcome the issue, as soon as possible.

As in the rugby game, the project team will be capable of thinking by itself. The coach hasn’t to enforce a defined set of steps to reach those objectives, and as in a real game the team has to learn to handle chaos of requirement changing and with emerging problems (even hoping that Italy will win the next 6 nations).

My considerations

In my scrum practice, I’ve appreciated the time estimation duty for each single task, as discussing with fellows or build a new feature. However, I don’t find it much helpful during the meetings because it’s an information that project managers need to check the process but not useful to the other developing members. The time estimations are closely related to the tasks, so why not to handle them with the issue/bug tracking system, jira for example? You might use it as a time monitor, so the scrum master can automatically obtain all required informations about the development’s progress.
The meeting is an opportunity to get together and to make it clear to others where you are, but most importantly, firstly explain your problems. Sharing difficulties among the members and get proper tips back make the team more integrated and helps to overcome matters quickly.

What impresses of the agile methodology practices is the communication approach, the synchronization of the developers and the feedback on a daily basis. Quick stand up meetings in the morning, before the activities start; maybe better with a coffee.

ICT in Italian companies

I recently read the article Le ICT non funzionano senza capitale organizzativo that could be translated as “ICTs don’t work without Organizational Capital”.
The source is, an authoritative source in matters of economical & political analysis, and this digression on Information Technology could represent an interesting prompt of discussion.

Some researches reveal the competitive gap of Italian firms compared to other countries’, and a corresponding lack of pervading ICT would be one of the causes of such a difference.
The investments in ICT between 2002-2004 allowed to reduce costs in paperwork areas, but the rate of companies that catch up the same results in strategic/productive areas is substantially lower .
The article argues how ICT affects Italian companies, and how this topic is so non-prioritized and misunderstood as a way to increase productivity.
I quote below some paragraphs of the article:

According to our investigation, the incapacity to obtain stategic returns is often due to:
1. Inadequate support to ICT investments by the top management, that often considers them as a “cost to be limited”
2. The difficulty of IT managers to have a clear vision of business requirements that such information systems must support, a factor which often leads to investements not in line with company strategy

The publication stab at the companies’ inertia to adopt proper organization models. The reason could be found in a lack of technological culture of the top management due to the small average size of the Italian companies that, therefore, have small resources to invest in organization/ICT restyling.

The remarkable elements in the companies which obtain best results by their ICT policy are shortly summarized:

The importance given to the human resources, a non-bureaucratic organization, the habit to share knowledge among employees, the adoption of performance-based incentives to individuals and teams, the presence of interfunctional team.