There is no spoon

After looking at my blog for the last weeks, I realized that I like most of the entries. I am particularly proud of some of them (e.g. The essential difficulty of software development).

I have also realized that it covers the same topics like many other blogs; for example Martin Fowler's or Jeff Atwood's. Those are the people who understood that human factor is extremely important in software development and have stated once and again the same principles and practices that I did. Though repetition is important – maybe people will learn if they see the same things repeated in different contexts, by different people, on different sites – I'm not sure that I can do a better job than the people I nominated.

There's also the fact that the MyOpera community is limited. It's a great community, it's vibrant, the people that participate to it are more interesting than in most other communities, and I really like it. From the technical point of view, it has almost everything you might wish for, including an amazingly effective SEO (the number of views on my blog are much higher than I expected and than I would have been able to do on my own). The only drawback for me is that most of the members of the community are not from my natural target audience: technical persons from European countries or from U.S.

I am thus faced with a couple of issues I need to solve:

• to change the focus of my blog
  
• to find ways to reach my target audience
  

Regarding the first point, I will make a few changes. I believe that the most interesting part of any training, book or blog is the personal experience of the trainer or writer. I will put more of my experience on the line. There's a lot to tell, since I grew with the Romanian IT industry starting from the point where there was no project manager until I took part in the CMMI level 3 effort for appraisal and then started to work seriously with agile methodologies, since I worked abroad (in France, UK, Switzerland, Belgium) and in more than five different industries (notably printing, banking, advertising, energy), with different technologies. I've held different roles in the teams, including software developer, business analyst, technical lead, project manager, software architect and consultant.
The second change is that I will write less often but with more research. There's no point in restating the same things again and again, while letting the readers make their own research. The main point of this revamp is that I want to provide added value to my readers. I like a lot how Joel Spolsky writes his posts, but it will take some time for me to get there.

To the second point. Since I don't want to leave the MyOpera community, I have a few possibilities: publish my blog in multiple places on the web (which may prove difficult), to market my blog to my target audience(no idea how) or to create a technical-related group on MyOpera (if it doesn't exist yet – group search is rather cumbersome in MyOpera). I'm yet undecided, and any piece of advice is welcome.

With these being said, stay tuned for the next developments of There is no spoon! New posts are already in the pre-production phase and will be published in a few days.

---

Personal advertisement: I am PassionIT and I help teams develop high quality software. I train, I help improving and I work hands-on, depending on the needs. Contact me if you need help. Alexandru Bolboaca-Diaconu

---

 

The Tester is one of the most important member of a software development team. Unfortunately, in many projects I've worked, his/her role was severely underestimated, resulting in low product quality and high costs.

I believe this happens because testing is a more difficult task than the common sense tells us. Testing software is hard because it hits the same essential difficulty as all other activities in software development: software is constructed from ideas. It's even worse for a tester, because how can one check that the representation of an idea corresponds to the idea?

Because of this fact, a tester has to have a few key skills:

• Smart, in order to understand the problem
  
• Attention to details, in order to be able to find even the issues burried deep in the functionality and in order to be able to fill the missing details from the functional requirements (there always are)
  
• Rigour, because he has to follow a process that allows him to check all functionalities, to recheck them periodically, to fill in the missing pieces and to improve the process
  
• Empathy, because he needs to understand the users
  
• Effective communicator, because he has to communicate both in writing (through test documents, bug reports etc.) and in speaking (with the developers, the business analyst, the project manager etc.)
  

If we add to those skills things like automatic testing, managing virtual machines and virtual networks, testing for security, stress testing and, the cream on the top, writing unit tests, we understand that a tester is a really complex character.

And a really important one, too. He has to work side by side with the development team right from the start of the project, because of simple economical reasons: studies have shown that bugs caught earlier are much less expensive than bugs caught late. Even a week difference between the moment when the bug is found may translate in a significant increase in costs: the developer locates the bug in a longer time, it's more difficult to fix it, it has to be re-tested and so on.

Therefore, if you want quality in your project, use a good tester and use him/her early. The price you pay for testing will be an investment, not an expense.

---

Personal advertisement: I am PassionIT and I help teams develop high quality software. I train, I help improving and I work hands-on, depending on the needs. Contact me if you need help. Alexandru Bolboaca-Diaconu

---

 

I have gathered some advice for young and passionate software developers. It comes mainly from my experience and from my peers'. I hope it helps.

1. Be aware that programming is hard

Despite what Microsoft, Sun and other software development tools vendors want you to think, programming is hard. It looks easy though. Start an IDE, run a wizard, do some work in a designer, drag and drop database tables, automatically generate code and everything seems to work just fine.
Well, in 99% of the cases, it won't. Something will happen that will make your application fail, and because you used an IDE, a wizard, a designer and because you don't know what's going on in the backstage, you're in trouble.

2. You're not done when you've stopped writing the code

You get a task from your project manager, write the code, compile and run the application once to see if it's working. If it's working, it means that you're done.
No, you're not. You need to test it thoroughly before you're actually done. Yes, there is a tester in the team, but bugs caught early are much less expensive than those caught in the testing phase. The project manager will insist on this topic.

3. A programming job means continuous learning

The only constant in our lives is change. You feel this even more in IT. New hardware, new software, new programming languages, new tools come up every year. There are good news however: the basic principles haven't changed in 25 years. Understand them and you will be less surprised. The bad news is that it takes time to understand them.

4. The technology used is not essential

C# is good. Java is good. Perl is good. Python is good. Hell, even Cobol is good. (Only VB and old ASP are evil :-D.) Each of them for their own domain. Learn them all. The more languages you learn the easier will be to learn more, and you will find innovative and effective solutions for your projects.


5. Solve the problem

Be pragmatic. You work for a project because somebody has a problem and they want it fixed. Find the best way to solve it. Yes, there are limitations. Yes, you can't always use the ideal solution. This is why you are asked to solve the problem and not a computer. There are no recipes. You have the capability to adapt to the situation. Solving the problem is the fun part, too.

I hope that helps!

---

Personal advertisement: I am PassionIT and help teams that develop high quality software. I train, I help improving and I work hands-on, depending on the needs. Contact me if you need help.
Alexandru Bolboaca-Diaconu

---

 

One of the core reasons for which software project fail is that managers and/or customers don't know the hidden costs of software development. Here are three of them.

Hidden cost #1: Unneeded complexity

Complexity is the enemy of a software project. Not only it undermines the productivity when developing the "too complex" feature, it also undermines the productivity of developing related features, of debugging, and of fixing issues. It undermines the moral of the team, produces headaches for developers and managers, and can also result in loss of personnel.

Complexity is fought with a variety of means, but all seem costly to an untrained eye: using good developers, good design, design reviews, code reviews, refactoring.

When complexity is well kept under control, the final costs of the project go way down. First of all, developers are happier, they are working better and get better results. Second of all, managers don't have to fight with them to get them motivated.


Hidden cost #2: Security

Only recently security has become a major ocupation for the commercial software developers. This only happened because of painful experiences and because it became clear that not taking security into account results in major losses.

Security is difficult to implement in a software. The only way is to use a holistic approach, to think of it right from the start and all throughout the process. It also implies additional development costs: training the developers on security issues, continuously monitor the code from a security perspective, implement specific security-related mechanisms that wouldn't be needed for an application deployed in the void.

Hidden cost #3: Choosing cheap but bad developers over good but expensive ones

Choosing cheap developers seems a very good financial decision. But there's a catch.

Good developers are often 10 times more productive than bad developers, and they are never paid 10 times more. On the other hand, if a team is formed of a lot of good developers, other will want to join it. If a team has only a few bad developers, either the bad developers or the good developers need to leave.

I've seen projects where good developers were fixing during the night what bad developers were implementing during the day, and they were not always paid for it. This is one reason for which this cost doesn't reach the financial balance. So, stop doing it!

So there you are: 3 hidden costs in software projects.

UPDATE: Martin Fowler talks about this third hidden cost in his blog.

---

Personal advertisement: I am PassionIT and help teams that develop high quality software. I train, I help improving and I work hands-on, depending on the needs. Contact me if you need help.
Alexandru Bolboaca-Diaconu

---

 

... is that we are working with ideas, not with material items.

The relation between people and ideas is fundamentally different from the relation between people and material items. For one thing, material items are perceived in the same way by different people (unless some of the participants are under the influence of some perception-altering substances). Material items can be described completely by diagrams and numbers.

The IT industry has gone to a great length of defining ways that would allow completely describing ideas. We have UML diagrams, templates for writing technical documentation and so on. We have ways to describe data and the transformation it suffers. We also have ways to describe the user interface.

The problem with the description methods we're using to describe ideas in IT is that:

• It's really difficult and time consuming to completely describe an idea (try to read Kant or Hegel to realize how difficult it is)
  
• Different people understand the description differently
  
• It's difficult for people to understand the description completely, to take into account all the details
  

Besides this, ideas evolve, and the people who need the application expect them to be easily included in the implementation. It's very difficult to dissociate an idea from its programmatic representation. Ideas are easy to modify; the implementation is itself immaterial; so why is the implementation so much difficult to change than the idea itself?

In order to prevent misunderstandings from happening, we are testing the "materialization" of the ideas; in other words, the implementation. But how do you test an idea? It's not a matter of fitting a mechanical piece in a mechanism. It's about comparing the mental image of the idea with the actual implementation. But you can't actually touch it, move it, look at it from all angles; at least not physically.

And then, there's the relation between users and their applications. The computer is different from any other tool known to man because of a few key characteristics:

• It processes information and the result is information
  
• It gives good results only when given good input
  
• It gives wrong results in any other situation
  
• The user cannot touch an application
  

Therefore, the user has to form a mental model of the application and of how it works. So we are back to the same problem of perception of ideas. The user's mental model about the application is not bound to be the same as the one of the developer, of the producer and so on.

This essential difficulty is responsible for the most problems we face in software development. And, because it's an essential difficulty, there are no ways to avoid it, only to alleviate its effects.


The first solution that comes into mind is to minimize the communication chain. If the mental model gets more corrupted the more it travels then make it travel less.

Open source is a succesful model because the people writing the software are the same people who need it, and they can take decisions regarding it. In other words, they are bound to have a similar mental model because they need the same thing, and they are free to adapt the ideas.

Agile methodologies are succesful because the communication chain is the shortest possible. The customer is part of the team and he is the one explaining the mental model directly to the people responsible with materializing it.

All the other methodologies have proven in time to be impractical. Completely documenting an application in UML is less productive than writing the application and adapting it as it goes. In fact, completely defining an application means that we are creating a complete representation of the application in another language, and isn't that exactly what programming does? Except that you can run a program and you can, with some extent, use your senses with a program. That's impossible with another abstract representation of the same idea.

The other way to alleviate the difficulty is to use the right people for the job. Since defining a mental model for the application is a human problem, it's dependent on the individual. People with the right mindsets and with a certain mental agility that allows them to adapt to exotic mental models manage to form a mental image that's much closer to the one that's transmitted to them. And, with experience, they come to the point where the fill in the missing parts with the correct pieces of the puzzle (for a very interesting discussion on the expert mind, see this article).

To summarize, if you want your software project to be succesful, do the following:

• Minimize the communication chain between the vision and the implementer
  
• Use the right people in your team
  

I believe this to be the basis for any succesful software project.

---

Personal advertisement: I am PassionIT and help teams that develop high quality software. I train, I help improving and I work hands-on, depending on the needs. Contact me if you need help.
Alexandru Bolboaca-Diaconu

---