There is no spoon

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

---

 

I have recently stressed the importance of having a team formed from very good developers in order to obtain software quality. I received interesting feedback regarding this statement, including one issue related to the ego of programmers.

The problem goes like this: you gather your best developers and ask them to work on a project. Instead of producing much more than the average programmers, they fight over design, libraries and principles.

I believe that there are a few key problems when this happens. First of all, design by committee has proved to be an anti-pattern. Second of all, because software development is about ideas, all projects should start with prototype implementations that are refined during the project's consequent phases. Third of all, there's the Ego Problem.

It is easy to see that developers often have an oversized Ego. That aspect can be very good or very bad for a project.

Let's take for example Linus Torvalds. Whenever he talks in public, he says "I'm always right, you're wrong. If I don't like what you say, I may say you're ugly and stupid". That's certainly an oversized ego.
On the other hand, nobody can say that Linux is not a succesful project. More than that, Linux is organized in such a way that Linus Torvalds doesn't control all its phases. And there's even more to the story: Linux might not have been so succesful if Linus Torvalds had a smaller ego.

I've also met the other type of developer. The one who thinks that knows everything, the one that doesn't agree with older and smarter people from the industry. The one who thinks his ideas are very bright when they actually are really bad mistakes. The one that tries to impose his solutions to everybody else.
I guess that this phenomenon takes place in Romania because the IT industry doesn't have tradition, doesn't have values, and it's not settled yet (actually, like the whole society). People still try to be original when they should just listen to the voice of the experience.

But what is different between Linus Torvalds and John Developer My-Solution-Is-Always-The-Best?
You can probably name a lot of differences. Knowledge and understanding are a few of them.

I believe that the main factor differentiating a Good Ego from a Bad Ego is the intellectual honesty.

If you read what Linus Torvalds says, you will see that he has no problem to point out his mistakes and his limitations. That's normal, because he works in an open environment, where all mistakes are noticed. If he doesn't talk about them, the others will.
At the other end of the spectrum, John Know-It-All will never accept he's mistaken, even if you prove it with all the resources you can. He will find out all sorts of ways to prove them wrong: "Those people don't do what we do", "This is theory", "I haven't seen this work" etc.

So there's one point to look for:

A person with a Good Ego is his/her first critic.

Intellectual honesty also includes the willingness to learn. Not only the technology you work with, but everything related to software development. Yes, that's hard, takes a lot of time and it's frustrating because you always find out you made mistakes. But software development is hard.

Continuous learning is the best way to transform a Bad Ego into a Good Ego.

My experience includes many moments of enlightment and of realization of my mistakes. I've come to understand that mistakes are part of life and that we should take maximum advantage from them. Understanding our mistakes and finding ways to correct them is how we evolve intellectually. During this process, a Bad Ego is transformed into a Good Ego.

The answer? Look for people who are intellectualy honest. This is an absolute requirement for what I call "good programmer".

---

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

---

 

Managers and marketeers have a thing with names; they have to translate everything into something easy to digest and that sounds nice.

I've been called during my career names like: C++ developer, .Net developer, .Net software architect. During my first years in the industry, it seemed OK. Now I know better.

It's true that I've worked mainly with Microsoft tools: Visual C++ 5.0, 6.0 and Visual Studio 2003, 2005. It's true that I've used Microsoft libraries: MFC, ATL. But that's only the surface.

I believe that what I did is more important than what language I used. Let's see a short list:

• I designed and implemented (with the help of my mentor) a custom database engine optimized for read only operations
  
• I improved the performance for a number of applications
  
• I worked on a number of tasks related to networking (sockets and stuff)
  
• I designed and implemented a resource locking subsystem in a distributed application
  
• Now I'm designing and implementing a Domain Specific Language
  

While knowing a programming language is necessary for all the above tasks, it's not enough.

On the other hand, I have evolved much besides the Microsoft world. I am currently using Linux at home, and loving it. I have finally understood functional programming only a couple of years ago, although I had passed an exam on this topic in college. I have understood that this whole discussion of patterns, procedures and other buzz words is futile; it's only programming. I have read about and used, within the available time, languages like Python, Ruby, Haskell, Perl and others. (In fact, even when working on Windows, I have a Cygwin instance open at all times so that when I need something I can quickly go in Python). Oh, and I know C, C++, Java, Javascript and C#.

For me the holly wars between Java and C# or any other two languages is just a pointless waste of time. If I think a language does a better job for what I need, I'm using it. If I think I need a new language, I'm designing and implementing it.

Finally, everything comes down to a few simple rules:

Be responsible
Know what you're doing
Take into account the advantages and the disadvantages
Use the appropriate tools
Solve the problem


So please, don't call me names; I'm a software developer, sometimes a software designer.

Update: Martin Fowler talks in his last bliki post about the different languages available for the Java platform. It seems we're on the same page about multilanguage projects...

---

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

---

 

Ever since I started to learn about computers and programming (I've read my first book about computers when I was about 10 years old), I've had a profound interest in the history of the domain. Not only the history of the first computers, but also about the cultural history of software development.

I don't know how many of the young programmers realize that they are part of a very alive and original culture. For me, the geek culture fits like a glove; many times I didn't know that a certain book or movie influenced the thoughts and ideas of the legends of programming, but I knew that I loved it.

But what is this culture coming from? Well, historically the programmers had certain tastes in books, movies, music a.s.o. Usually their interest lied in science, science fiction and very strange humour.

Let me give you some examples. The british humour group "Monty Python" was so influential on the geek culture that some people who decided to design a new programming language named it after the group. You guessed it: it's now called Python. Its documentation is filled with samples of the group's (really strange) humour. One of my favourite Monty Python quotes relates perfectly to many IT projects: "The purpose of this year's expedition is to see if there are any traces left of the last year's expedition" - from the Kilimanjaro sketch. (Hint: replace "expedition" with "project" and you get the point)

Another example is Douglas Adams' five parts trilogy "The hitchhiker's guide to the galaxy" (Hint: Forget the movie; you have to read the book). This book was so influential that the "answer to the final question about Life, the Universe and Everything", computed by the most powerful computer from the galaxy, namely the number 42, has a myriad of cultural references in IT. The simplest one that you can find is when you google for "the answer to life, the universe and everything".

J.R.R. Tolkien's masterwork "Lord of the Rings" is another notable part of the geek culture. More recently, the movie "Office space" created a number of memes, notably the TPS report. And so on.

As I said before, I feel that I am part of this culture. As a result, it was only natural that I participate to it. Therefore, when I thought about how should I name the domain specific language for rules that I'm designing and implementing for my current project, incidentally related to semantic web, I heard a bell ringing. See the result below:

One language to Rule them all
One language to find them
One language to bring them all
And to the ontology bind them

I hope that's not too much for my readers ;-).

PS: Please Mr. Tolkien, Sir, don't turn me into something unnatural...