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

Why the CMMI or other standards have remained unattractive or avoided by software giants?

, , , ...

This is a question from LinkedIn that I answered today.

Why the CMMI or other standards have remained unattractive or avoided by software giants, compromising the software quality, and providing later on with service packs and patches to be applied?

Many software giants are not in the favour SW-CMM or P-CMM or any among the whole CMMI, just because they simply does not want the lengthy assessment to be performed on regular basis which may impact the right time to deliver the product, opening the major loopholes in the software product. Therefore, it is tendency to offer service packs and security patches after the software has been delivered without going through the quality procedures offered by CMMI like standards.


The short answer is because most software giants base their projects on people rather than processes. The Google example is the most well known, but Microsoft, Sun or IBM have similar policies.

The idea is that quality software requires discipline, and there are two extremes in the discipline axis: on one end you have disciplined people to work with and on the other you choose to follow certain processes to the letter. CMMI's focus is mostly on processes, while Agile methodologies (Scrum, XP, open source etc) focus on people.

This doesn't mean that a framework like Scrum has no rules; it does, but one of the first is that the team is self-organizing. I saw statistics related to Scrum and the results are impressive.

So, if you look to what software giants are using you will see that they are using one or more flavors of Agile: Microsoft is using MSF, Google is using Scrum, XP and some other flavors, IBM is using CMMI in some departments, open source and some form of agile in others etc. This is simply because a well implemented Agile framework gives much better results than CMMI.

Regarding the Service Packs and patches, in today's business world there is absolutely no way to eliminate them, no matter which methodology or framework you are using. You can reduce the number of issues through some engineering practices (which are common to all methodologies) like inspection, unit testing a.s.o., but the even if the software is perfect when you release it (which surely isn't), new threats and changes appear every day. So, the business reasons will push you to release new patches and service packs.

I don't say all this to defend Microsoft. I believe that their mistake is not in the way they build the software; it has much improved in terms of security and stability. Their mistake is in the way they are using the software as a business weapon; instead of doing the best software they can, they try to kill the competition with it. Sadly for them, it doesn't work anymore. Sadly for their users, they are still doing it.


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

Keep It Simple, Stupid (!)

, ,

One of the most successful principles of engineering, including software development, is KISS = Keep It Simple, Stupid. (I sometimes think of it as Keep It Simple, (you) Stupid!). Here are a few of my personal experiences with this principle.

Last year, a few co-workers developing a ticketing project came to me asking for advice regarding a role, permission and resource based access control system. The presentation of the requirements took about 30 minutes, and I was still confused on some points. Therefore, I stopped the discussion after the requirements presentation, asking them if the customer knows how intricate and difficult it is to define such a system. I told them that no matter which bright hacker they would have as consultant, the effort required will be immense. I mean, its complexity was similar to the Windows implementation of permissions. My message was, basically, keep it simple.

Talking about Windows, does anyone really understand Windows permissions?



For example, can you tell me what “Special permissions” are about? Did you ever see the advanced permissions? What is “Write Extended Attributes”? Honestly, to me, it makes no sense. I've never passed the phase where you create some users, add them in a group and give full control to the group on specific resources. The whole thing is too complex, and it's not really useful for most users.

Contrast this with the Linux way:

Every file or folder in Linux has access permissions. There are three types of permissions (what allowed to do with a file):
  • read access
  • write access
  • execute access

Permissions are defined for three types of users:
  • the owner of the file
  • the group that the owner belongs to
  • other users

Thus, Linux file permissions are nine bits of information (3 types x 3 type of users), each of them may have just one of two values: allowed or denied.
Simply put, for each file it can be specified who can read or write from/to the file. For programs or scripts it also can be set if they are allowed to be executed.
(whole article here)

Not only you can read and understand it in 30 seconds, but you can also relate immediately to what it talks about. It's useful, it's usable, it works. You don't have to think about whether you should:

inherit from parent, reset permissions, or overwrite them.

Another example is what happened about a month ago. We were discussing the GUI for editing a number of items organized in a hierarchical structure. Trouble was, save and cancel actions had the potential to create strange side effects. You would open a popup dialog, edit something in it, save it and the question was if all the items needed saving at that point. If not, then the referential integrity was not preserved. If yes, you saved the items from a popup who was supposed to save only the thing you edited in it.
After throwing a few ideas, we realized that there's a simple way to solve it: automatically and always save everything in background, like Gmail, Makagiga and other modern applications. This not only solves the referential integrity problem, simplifies the logic of the application but also proved to have benefic side effects in the code. A perfect example of KISS.

Another example is Mantis. Mantis is an incredibly effective issue tracker system, both easy to use and full-featured. It also happens to have a few touches of genius.
The first thing that made me say that was the fact that the issue number in mantis is unique, no matter in which project it is contained. This means that you can discuss with your customer about issue no. 1234566 and go directly to it, without having to navigate through the 100 projects of your organization.
Another splendid idea is the presentation of issues reported by a person who left your team. In mantis, you still see the name of the person, but it is presented with strike through, like this: Alex. Simple and effective.

Certainly, simple solutions are the most difficult to find. You need to invest time, involvement and lots of brain power into it. You need to keep reading, seeing what others are doing, searching ideas and have the courage to use them. It may not look so smart when you implement it, but it will certainly raise a few eyebrows when it's ready... Or, if you're really good at it, you'll say in the end: "I was so stupid. How didn't I think of this before?"


For anyone who's interested, here's some additional reading about how to apply the KISS principle:
  • Getting real, a free online book by the developers of Ruby on Rails, BaseCamp and other successful applications
  • The Art of Unix Programming, chapter Basics of the Unix Philosophy, a free online book about sound design, a must read for any serious software developer. If you don't have time, read at least this page; it's an amazing resource
  • The Humane Interface, a book about GUIs written by the man behind the MacOS interface, Jeff Raskin. It's not free, but you can find its summary online, along with many other essays by the same author.



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

The death of a visionary

, , , ...

I wrote before about the litterature of Arthur C. Clarke. I said then that I didn't think of him to be a good writer. However, I have the outmost admiration for him as a visionary and as an engineer.

As most people have probably found out already, Arthur C. Clarke died today. I am one of those who will regret it. In a sense, I've grown up with him, with his ideas and with the ideas that he inspired. Even though his books were not litterary interesting, they certainly were compelling from the engineer point of view.

I'm sure that, even though he died, we will still hear about him. I hope that the Arthur C. Clarke space elevator will soon see the light of day, along with many other of his ideas.

As an engineer, I'd like to learn from him how to imagine practical future solutions for complex problems. He was amazing in this aspect.

Mr. Clarke, I for one will always remember you, and will always be inspired by you. Rest in peace.

How to be productive when writing code

, , ,

I've gathered a few rules that, when followed, increase productivity of code writing.

Rule No. 1: Solve the problem in the simplest way possible

We are often tempted to think of intricate mechanisms that solve a problem. We are often tempted to generalize the problem and prepare for a future that never comes. We often solve another problem or we solve the right problem but in a complicated way.

I can empathize with this. There's a certain beauty to a system where many wheels turn in a perfect way and work together to solve a problem.

The trouble is that a complex system is complex to maintain. What initially seems a simple but powerful generalization, or the use of a beautiful method for solving a problem proves in 99% of the cases to be off target, difficult to understand, non-functional, difficult to modify, difficult to maintain. Therefore, a small "exageration" in coding produces a cascade effect that may live up to the end of the project.

When you think at it this way, you understand why everybody says that the code should solve only the current problem and only in the simplest way possible. There's always time for smarter approaches later (see rule no. 3).

Similar rules: Don't overengineer, Keep It Simple and Stupid

Rule No. 2: Write first, edit later

We have the tendency to think at better ways of solving the problem during coding. Don't do that: separate writing code from making it better.

Programming is creative work. You have to let ideas flow and to put them on screen as soon as they come. But when you do that, don't concentrate on all aspects. For example, error management can be added later. Methods can be extracted from existing code, once it's written. New classes can be created later.

I'm not saying that you shouldn't do any of the above when you write the code. Write whatever you feel natural to write, but avoid getting stuck in boilerplate or code organization issues. Make decisions on the way, as soon as possible, so that you continue to write code uninterrupted.

I've seen this work while writing the parsing code for the DSL I'm developing. If I thought of all the patterns, of the structure of the code a.s.o., it was ready in twice or three times the workload it took me. Sure, I have to revisit the code and refine it, but that's exactly the point.
Good code doesn't get born out of thin air; it is the result of multiple refinements.

So strive first to minimize the time needed for obtaining functional code. Add the bells and whistles later.

Rule No. 3: Refactor periodically

This third rule completes the circle. You solve only the current problem, in the simplest way. You write first, edit later. And you do this on a number of functionalities.

After a while, you realize that you can generalize parts of the code, or that some methods or classes repeat almost identically in different parts of the project. It's refactoring time.

But be careful: Refactoring means modifying the organization of the code without modifying its functionality. You are not allowed to add functionality (maybe only as a by-product). You are not allowed to change the existing functionality. You can do only a number of things: extract method, extract class, move method, simplify code etc. (you can find them all in Martin Fowler's book about refactoring).

And here you are: three rules for writing code better and faster.


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!

Threat modelling

, , , ...

I have a very difficult task those days: defining guidelines to ensure the security of a distributed application.

Despite the Oxford study that shows that engineers have a way of looking at the world that is similar to terrorists (?????), thinking as a hacker is not straight forward. And that's exactly what I have to do.

More than this, it's a job that involves great responsibility. It's important to review and validate all the assumptions and to test the results.

Anyway, I'm using the threat modelling methodology, which basically means the following steps:

  • Imagine all the possible attacks to your system (of course, there are already lots of papers describing possible attacks; I am using them as a starting point)
  • For each possible attack, evaluate its probability and the effects if it happens
  • For each possible attack, decide if preventing it is necessary and/or possible
  • For the remaining attacks, define the prevention measures
  • For all attacks define the contingency plan (what to do if it happens)
  • Translate the prevention measures in coding guidelines, test scenarios and maintenance procedures

Of course, in real life things are more complicated; for example data needs to be partitioned in sensible information (for example private data, commercial data etc.) and non-sensible information (for example lists of countries). Data Flow Diagrams are also very useful in order to follow exactly where the data is going, and so on.

Those steps should always be followed by many reviews, by training developers to follow the guidelines and by enforcing the guidelines.

I like this methodology because it starts from real world questions: What can an attacker do? How difficult is for him to do that? What are the effects of an attack? It also forces the analyst to learn about software vulnerabilities.

There is however another facet of any attempt to security: it always involves the human factor. I won't go in this subject now, but I recommend Bruce Schneier's blog for a very smart and insightful view on security, especially when it involves the human factor.


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!