Skip navigation.

exploreopera

| Help

Sign up | Help

There is no spoon

It is not the spoon that bends, it is only yourself

Posts tagged with "improvement"

Blog Focus and Target Audience

, ,

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
Add to Technorati Favorites  Digg!

Blog revamp

, ,

I have reached the conclusion that I am not happy with the average quality of my posts. There are some which I like, but there are many which feel incomplete, for which more polishing time would have been needed. (Feel free to contradict me here ;-)

Therefore I am setting myself a two weeks deadline for improving my blogging. Changes will happen in my blog during this time, but I won't add new posts as often as until now.

I want to have at the end of the two weeks the following things:
  • Old posts that are good, in my view, will be refined and republished (version 2)
  • A way of working that would allow me to keep my blog quality consistent


For the second objective, I expect a few changes to happen, namely I expect to post less often and to do more research and polishing before publishing.

I don't really think that metablogging is interesting to readers, but since my main activity in the following weeks will be to improve my blog, I will probably post about it.

Well, that's it; talk to you soon, and hopefully, better!

The other half of agile practices

, , , ...

I believe that agile practices are some of the less understood topics in software development today.

Just do the following, very simple exercise: answer the question "what do you think when you hear about agile?"

The list of answers I'd think of is:

  • less documentation
  • people are more important than processes
  • refactoring
  • the developers get involved in the project


It turned out that my list is wrong. Its substance is not wrong, but it's utterly incomplete.

I only got half of the picture, and I believe so do many other IT professionals.

The trouble is, if you take each of the above principles and apply them, you will get really bad results. I can't think of a better way to illustrate this than an older Dilbert cartoon:



I've recently had the chance to find out about what agile really means from one of the Scrum creators, Jeff Sutherland, through my wife (who is now a Certified Scrum Master). Even if I wasn't directly in connection with him (though I would really have wanted to), I found out a few very important things.

First of all, there's no such thing as agile. There's Scrum, there's XP, there's open source and so on. But if you say that you're working "agile", something is wrong.

Second of all, Scrum is about the common sense. That's something I already knew and fought for in the context of my previous projects. Some of the most common mistakes due to lack of common sense are: not testing the application, not allowing developers to do their magic, trying to plan and to adapt the plan to continuous change, not using continuous integration and the list may go on.

Third of all, Scrum is applied succesfully by many companies at different levels. The most extreme Scrum approach is to put all tasks from all projects in a common backlog and transform all your company in a self-organizing team that works on this backlog. Sounds scary, but it works.

And last, the role of the architect in Scrum is really really important. The architect is the one who looks a little bit forward, but not too far, who creates a general but not too general model. He/she has to walk a really thin line, and the team is depending on its success.

There are many other interesting aspects about Scrum that I can't treat here. I just wanted to show you that I was wrong about agile, like, I believe, many other IT professionals are.

I am open to discussions about this topic that interests me profoundly, especially because in Romania agile development is even less understood and properly used than in other parts of the world. Let's talk about it, shall we?


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
Add to Technorati Favorites  Digg!

The Ego in Software Development

, , , ...

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



Add to Technorati Favorites  Digg!

5 things managers don't get about software development

, , , ...

1. Software development is creative work

How do we know that's true: All rules that apply to creative work are known to give results for software development. For example: write the program, then re-write it at least once (see [1], [2]).

How do we know managers don't get it: The cubicle. The noise. Any other environmental factors that kill creativity.


2. Managing an IT project is different than managing projects in other domains

"In many ways, managing a large computer programming project is like managing any other large undertaking — in more ways than most programmers believe. But in many other ways it is different - in more ways than most professional managers expect."
(from [1])

How do we know that's true: Practices that work in other industries don't work in software development (for example adding more people to a project to make it end faster or motivating people with "the employee of the month" program)

How do we know managers don't get it: They still think people are interchangeable in a project team and they still use ineffective motivation and recruiting techniques.

3. People are more important than processes

How do we know that's true: No software company has succedeed only based on processes. Instead, all software companies that are very succesfull have very good people. The best example is Google.

How do we know managers don't get it: They still insist on the work processes instead of attracting talented people and instead of making sure that they reject the wrong people. (See [3] for an interesting story regarding this issue).

4. Good developers are cheaper than bad developers

How do we know that's true: Data from the industry shows that good developers can be up to 10 times more productive than bad developers (see [1]). From my own experience, there are cases when bad developers can be even worse than that. But good developers are never paid 10 times more than bad developers.

How do we know managers don't get it: They prefer to hire cheap but mediocre developers instead of hiring talented people.

5. No bad developer has ever become a good developer

How do we know that's true: Even Bill Gates said it. There are studies about it (see [5]).

How do we know managers don't get it: They still hope that bad but cheap developers will learn in time.

References:

[1] Frederick Brooks, "The mythical man month"
[2] Eric S. Raymond, "The art of Unix programming"
[3] Paul Graham, http://www.paulgraham.com/colleges.html
[4] Joel Spolsky about recruiting software engineers: http://www.joelonsoftware.com/articles/GuerrillaInterviewing3.html
[5] Saeed Dehnadi, Richard Bornat, Research Study about Programmer Aptitudes, http://www.cs.mdx.ac.uk/research/PhDArea/saeed/


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



Add to Technorati Favorites  Digg!

I'm not a C# developer or a .Net software architect; I'm a software developer, period

, , , ...

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



Add to Technorati Favorites  Digg!

Writing less code is good for your software's health

, , , ...

In a previous post I criticized some of Jeff Atwood's ideas. Today it's time to step in and defend him.

Jeff Atwood's today post talks about being able to run a program in 600 lines of code. He calls for an exercise in minimalism:

What can you build in 600 lines of code? Think of it as an exercise in minimalism. Does your preferred language or environment allow you the freedom to create something interesting and useful with that constraint in place?


The comments to this post are mostly jokes for a matter that is quite really serious.

I suppose that everyone's heard by now that the software industry has a horrible failure rate. 30% of projects never finish, while other 30% of projects finish but not in the due time and/or budget. That leaves only about 1/3 of the projects that are really succesfull.

Imagine now that one in three cars would explode and another one would be delivered one year late. Or that one in three houses (bridges, airplanes and so on) would fall apart. This is the sorry state of the software development industry at this point. Our only luck is that our mistakes kill much less people than other industries.

There are many reasons for the failure rate. Some of them are related to the fact that most managers don't understand how software is produced and don't know how to improve the process (hint for the managers: read for starters "The mythical man month", "Code complete", "Peopleware" and "Software Estimation: Demystifying the Black Art"). Some of them are related to the education of programmers.

When all those things are done well, the final product has a few characteristics that show it's good. The Tao of Programming explains it in a very expressive way:

A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity.

A program should follow the `Law of Least Astonishment'. What is this law? It is simply that the program should always respond to the user in the way that astonishes him least.

A program, no matter how complex, should act as a single unit. The program should be directed by the logic within rather than by outward appearances.

If the program fails in these requirements, it will be in a state of disorder and confusion. The only way to correct this is to rewrite the program.


The connection between good software and fewer lines of code is well documented (again, see "Code complete"):

The more lines of code your software has, the greater the number of bugs.
The more lines of code your software has, the longer it takes to solve one bug.
So writing less code helps you write good software.


Any software can be written badly. The experience shows that this category of software usually fails. So, how's it gonna be?


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



Add to Technorati Favorites  Digg!

Soft skills in software development

, , , ...

I think that the developer's soft skills are not stressed enough. There's no curriculum, lecture, book, blog or journal that talks about soft skills necessary for effective software development.

The issues are of course mentioned. Frederick Brooks in "The mythical man month" and Steve McConnel in "Code Complete" talk about communication, about understanding the customers and so on. That's not enough, though.

The two things that helped enormously my career until now were soft skills: Foreign Languages (English and especially French) and Empathy. Of course, the hard skills are important, but that's covered pretty well in the litterature.

My knowledge of French allowed me to work with French speaking customers, thus enlarging my experience and my demand. The empathy allowed me to understand my customers, to understand their needs, to minimize the communication time and to deliver what they requested. An interesting fact is that I've educated my empathy by studying people during the college years, and today I congratulate myself for that.

So here it is, another remark regarding the human factor in software development:

Empathy is largely underestimated as one of the main factors that contribute to the success of a software project.

If you can understand your customer, your co-workers and the human nature, the only obstacle between you and a succesful software project is taking the right technical decisions. And who takes them? Again, the team members. Wouldn't it help if they could communicate effectively with each other? You bet.


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



Add to Technorati Favorites  Digg!

Plans for my 31st year

, , , ...

Today is my 31st birthday. I spent most of the time trying to learn more about the big world; I don't think I'll ever stop, because it's still very exciting and because new things come up all the time. I've worked for about 8 years in IT, and I still like it and learn about it. My experiences are varied: I've worked in 5 different countries and for more than 5 different industries. Last year I was lucky enough to get closer to the edge of the domain; continuous integration, domain specific languages a.s.o. are now part of the daily activities.

I am thus happy on a professional level because I have a lot more to learn and a lot to talk or write about. I will keep writing this blog, and I am planning a facelift for my website. I'm even considering starting a book about my view of the world.
The wikimagination project is another effort I believe in. It's still a mistery how will I manage my time between work, blog and the other stuff. I hope to find a way...

Those are my plans for this year. Let's see how it goes on, shall we?

Hobbies

, , , ...

I believe hobbies are very important for any human being, and I'm not excluding programmers from this category. I believe than any person should know what he/she likes to do besides work. This is the key to a balanced lifestyle, and, maybe even more important, to personal improvement.

Personally, I like to read, travel and cook. I visited most countries in the Western Europe during hollidays, and I'm ready for more. I fancy, for example, a trip to the Inca remnants from the Andes; it is a little bit problematic because it's expensive and because I need to get in shape, but I'm willing to make an effort. I have mixed feelings about the U.S.; I'd like to see the Grand Canyon, but I'm not sure if cities like New York or Los Angeles are worth visiting, since I'm not that much into modern architecture. Until then, I will certainly go to Tuscany and to Barcelona and surroundings. Honestly, I can barely wait.

I already discussed about my passion for reading. If interested, take a look at my Shelfari bookshelf.

I'm cooking quite often, usually Romanian food (Sour Soups, Polenta etc.) or common plates, like grills (always marinated), skewers and other types of meat plates. I'm also cooking breakfast in the week-ends, meaning omelettes and sometimes pancakes.
I like many things about cooking. First of all, it's a relaxing activity; I can listen to music, talk to my wife and even play while I prepare something. Second, it's a social activity, when we have "kitchen guests". It also allows me to explore the world without going too far; for example, today at lunch I cooked for the first time a Chinese recipe, Stir Fried Beef with Three Vegetables. On other occasions I've tried fried rice (Asian recipe) or Basmati rice with safran. More than that, I learned many words in English and French, in order to understand the recipes. True, I'm still unsure sometimes, but that's part of the adventure.

I feel fine at home, and forget about my work. I think that's a good thing, because every day I come back with batteries reloaded. My hobbies have a lot to do with this.

Do you have any hobbies?