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 "work"

Cheering vs. Getting Involved in an Open Source Project

, , , ...

I know many developers, including myself, who show an undeterred belief and a continuous fascination in the open source development model, but have never participated to any open source project. Some of them, including myself, even work on commercial applications based on Microsoft technologies. Some of them, including myself, have never edited a Wikipedia page.

This is at best paradoxical. How comes that people who are such believers and supporters of open source are only users and cheerleaders instead of getting involved?

Maybe it's because we are Romanian, and we are used with such paradoxical behaviors. Or because the difference between cheering and doing is very very large. Or because programming actually is hard. Or because we like the idea in principle, but we don't have the courage to start living it. And I can think of a couple of other reasons.

Regarding myself, I tried to choose an open source project to participate in. First I tried Mozilla then Open Office and I found out that they are really complex projects and that the time to enter such a project is quite high (incidentally, Open Office recently became much more contributor-friendly, with its new website). Then I looked at smaller projects that I was using: ArgoUML and PostSharp. Still no luck - they didn't manage to capture my attention, although both are great pieces of work. I even tried to open my own open source project, something I think would have been a cool application - a "send to"-like tool allowing not only to send data to an application, but also a "send as" option allowing to transform the data into something else before sending it (e.g. "send to thunderbird as attachment", "send to thunderbird as zipped attachment" etc.). I didn't even find the time to add the document describing the mechanism and the prototype code to its sourceforge account.

There are many reasons why this happens. First, I wasn't very familiar with Linux until recently, and Linux is the best open source development tool because all the libraries you need for development and their documentation are a command line away (be it tar, apt-get, slapt-get or any other command). I very much miss the installation super-powers when I work on Windows.

Second, my time is fragmented, no matter how much I try to organize it. I have development tasks to finish, then I work on some training materials, then I think about my website, then I think about my blog, then I work with my wife on projects coming through her company and so on. And I find that many times the learning curve for an open source project is too steep, and I don't have the time to invest in it.

Third, I got used with giving my time on demand, instead of donating my time. If somebody asks me to help at a project, I would jump in the bandwagon as soon as I think it's interesting. But that's not the open source way. Rather, it's me who should find a project that interests me and to invest in it.

Maybe that's just me, but I think times have changed since The cathedral and the bazaar. The number of open source projects has exploded, and the large majority of them fail. There's nothing wrong with it; it's only the selection of the fittest, but who likes to jump in a probable failure? And, even more difficult, who has the time to look at all new open source projects and choose one that's interesting?

I'm not saying it can't be done. I'm just saying that I don't know how to do it, and that I'd very much love to participate to an open source project that fits my knowledge, my skills, and who can capture my attention. So, if you work on an open source project, please let me know how you solve those problems.


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

The Tester

, , , ...

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
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!

Review of a company review web site

, , ,

A relatively new Romanian web site has the potential to give headaches to company managers from Romania. Basically, the site allows anyone to write anonymous opinions about companies. As a result, a lot of people complain about how bad a company treated them. The number of positive posts is very low compared with the negative ones, and the positive posts are often regarded with suspicion.
On the other hand, some of the information you can find on the site shows just how bad some companies treat sometimes their people. This is useful information, and I can certainly see the necessity of such information being disclosed in a public space.
The site doesn't however a very good job of providing unbiased information. From what I know, anybody who did a very poor job and got fired or was convinced to leave through different means will write about his/her bad experience, sometimes in a hyperbolic way (they never do that or they always do that, which is most probably not true). On the other hand, only a handful of happy employees will write about their good experiences.

To sum it up, from the point of view of someone who would like to find out more about the work conditions from a company, the site as it is now is not trustworthy. One cannot trust even the companies that are not discussed on the site, because there might be something wrong when there's no fuss.
From the point of view of companies, the lesson should be that they should become more transparent and give more information for their potential employees. They shouldn't however attempt to control information, because this will only make them loose time, with even worse effects.

My broader conclusion is that the age of information has come. Any attempt to fight this will be a big failure. Instead, learn how to go with it.

Sleeping late and doing great

, ,

My friends know very well that I'm not a natural born morning person; in fact I was heard many times telling people that all that comes before 9 AM is very early. Of course, on the other hand, I don't go to bed early, but some time during the night.

It so happens that during this week I had to wake up at 7:30 AM every morning, and, strange enough, I don't feel that's bad. How does this happen?

I think that's a matter of what you do rather than when you do it. If you do something that's interesting (as I happen to do now), I am really happy to wake up early in the morning. If you go to a job that doesn't challenge you, that's not interesting for you and you just go there to take the money than waking up early is just not worth it.

So if you don't like to wake up in the morning, maybe the question you need to ask yourself is: do I have what to wake up for?