On Software Development – Why is it so hard?

Hello there! If you are new here, you might want to subscribe to the RSS feed for updates on this topic.

Making software is hard. The better you want to do it, the harder it gets. And given the question “Why is good software that hard to do?”, the answer is neither simple, nor straightforward, and there are plenty of reasons for this to be so.

I was recently interviewed (note: interview language is Romanian) by a Romanian online publication, and I was asked about the originating idea behind FlairBuilder. I will not get into details now about that idea (I will keep it for another post). I just want to say that there was a need, a need that determined me to start this project and keep working on it for almost 2 years now. Simply said, I felt the need for a better way to create software, better in the sense that it should be more accessible to those that know how it should work and how it should look like.

Now, let me detail a bit what I have in mind. Most of the software that we use every day has two main dimensions: a visual one, also known as the Graphical User Interface, and a non-visual part. If on the non-visual side the problems to solve are generally technical and the range of solutions is pretty much limited, the User Interface (what the user sees and use) is enormously much more complex and diverse. One can think of a lot of variables that make User Interface development harder, variables that are hard to identify, quantify and manage. From technical limitations to user psychology, a broad range of problems may encounter in the process. Taking all these into account may become tedious and expensive. Neglecting them could be dangerous. Keeping a balance requires good expertise, involvement, and careful analysis.

Let’s ask ourselves a question: “Why is software created in the first place?” The answer should be simple enough: “Because someone needs it.” So the entire software creation process should read as:

1. A expresses the need in way Z can comprehend/apprehend. That is, in the language and in the very specific terminology that Z feels comfortable with.

2. Z creates a software that A understands and know how to use and, of course, fulfills his need.

As simple as that, one may think. The key element here and very back-bone of every software development team and process is communication. As simple and obvious it may sound, this is one fundamental piece that if not functioning correctly will most certainly ruin a project.

Although tons and tons of literature was written on this subject, we still sometimes find ourselves having wrong expectations from the wrong people. We still think that the other one sees and perceives the same semantic content in the words we use to express ourselves. We neglect, for instance, the amount of self implied in most of our assertions. We expect people to understand or to imagine what we don’t explicitly state, something that only someone with a very similar background will actually be able to do. Too many times I found myself amazed of how much explanation effort I had to add to a simple thought. The same on the other way: So many times I had to open my ears really, really well to actually get a closer felling of the message some one was sending to me.

The fact is that there is absolutely nothing wrong with this. It’s just the way things are and we must be aware and deal with it properly. Because that’s where this language/terminoloy difference starts to become a problem, when one starts to talk in a language the others don’t fully understand, without at least being aware of this.

But what if I’m not multilingual? What if I simply can’t make myself understood to someone with a different profession or different background? What then? The answer is simple: Get a translator. Exactly as we do when going to France or, better, Japan or China, the same way we need translators when talking with people who have little things in common with us, professionally speaking. For instance, a Business Analyst will go and understand the way a specific business is working and will come back with a full stack of papers and hand it to the Software Engineering team. Or an User Experience Designer will understand the specific set of users targeted by a certain product and will make sure the product user interface is well suited for those users.

Both the Business Analyst and the User Experience Designer act as translators between Software Engineers and other categories involved the software creation process.

Of course, a translator is not always available, and each of one involved in a software project should make a extra effort to understand and make him/herself understood. It doesn’t have to be hard. I guess that we need to listen more, ask more questions and should not mind answering more questions. Address the same thing from different directions and see if one answer really stands up when faced to two or more different point of views.

And finally, I think that is very important to take decisions based on tangible assets such as wireframes and prototypes. As technical as it may sound, there isn’t a more efficient and certain way to get to mutual-understanding than something that mimics the desired product: in both layout and behavior. An interactive wireframe, or a prototype as produced by FlairBuilder or other tools, do make a difference in the communication between developers, architects, designers, managers and, finally, the client.

My two very little cents on the matter.