Is writing software easier than reading and understanding it from scratch? [closed]

Question

Me and a friend of mine were discussing yesterday about differences between writing a large C++ software and understanding it as a new recruit.

Is it possible that since a software gets done one line at a time and this process resembles how we (humans) learn things and build a thing on top of another one, writing a large software is actually easier than reading it and understanding what it does (stepping through the code helps but you need to remember multiple classes/source files together you don't even know what they've been written for, multithreaded code adds malus points)?

This sounds weird at first but after we thought a bit it seemed reasonable

Answer 1

Based on my experience, I would rank the following activities in order from easiest to hardest.

1. Reading good code
2. Writing bad code
3. Writing good code
4. Reading bad code

The above ranking leads to 2 conclusions

1. While it is easier to write code than reading bad code, it is easier to read good code than write your own code
2. Writing bad code is easier than writing good code, but writing bad code sets you up for reading bad code, which is the hardest thing of all. Especially since bad code is read more than it is written.

Of course, good code and bad code are broad generalizations. I recommend Code Complete and Clean Code for more details about good code.

Answer 2

This question appeals to a False Consensus. http://en.wikipedia.org/wiki/False-consensus_effect

Different people learn and absorb information differently. It's akin to auditory learners, visual learners and kinestetic learners. For some, reading code is easier, for others, creating code is easier. For me, it is the latter. For others on my team, it is the former. I don't believe finding some kind of consensus or majority is useful. It is better to understand how your brain absorbs and learns information and use that knowledge to make yourself better and to learn to accept others who are different.

Answer 3

differences between writing a large C++ software and understanding it as a new recruit

This isn't the same thing as the difference between reading and writing software. When you're new to a project (and especially when you're new to a company) you have a lot more to learn than just what the code does. Understanding why the code does what it does often requires an understanding of how the business works and how the project relates to the rest of the organization. In short, reading code without the benefit of background knowledge is a slower, more difficult task than reading code when you fully understand the context in which the code works.

There is a difference between writing brand new code on a greenfield project and reading and modifying existing code, but I wouldn't say that one is necessarily easier than the other, just different. When you're creating something new, you don't have to worry about how to make your code work with what's already there, but you do have to worry about making your project sufficiently extensible and adaptable that it'll remain useful into the future. When you're working on an existing project, you can often use what's already there as a guide, but you must first understand what's there.

As a "new recruit" it's usually better to work on an existing project specifically because it helps you to learn all the things you don't know: how the business works, how the various projects work together, coding standards and practices, and even (especially) what could be improved.

Answer 4

It's an interesting question, but I would tend to lean towards the side of it being easier to read and understand than it is to create it.

If you are a veteran, seasoned programmer, then you are likely to read through code and go "Yeah, good choice, check, oh, I might have done X instead of Y", etc. You may modify or tweak, but that would save immense time over writing from scratch (Unless there are reasons for doing so).

If you are a newer programmer, then "you don't know what you don't know", and so you are going to have to invent/learn all the little things, and very likely you are going to have some inefficiencies in the code. You will likely develop a greater understanding of the language, however.

But in both of those cases, it's going to be easier to read the code and go from there than it is to write it completely from scratch.

Answer 5

Most programmers find it easier to understand code they wrote themselves compared to code other people wrote. This is due both to the line-by-line learning you mentioned, as well as just a matter of individual style and talent. That's why so much wheel reinvention happens.

However, that's the view of the trees. The forest view is that it's much easier to read code than to write it from scratch. For example, is it easier to write a new word processor from scratch, or to learn an existing code base well enough to make improvements?

When you start reading the code, you can think of a bazillion ways to make the code easier for yourself to read. You spend the first while just tracing code around, trying to figure out the lay of the land, sometimes in an architecture completely anathema to how you would like to do it. But even in really large code bases, you'll spend maybe 40-80 hours spinning your wheels, compared to the hundreds of thousands of man hours already invested in creating that application.

Answer 6

The person writing the piece of software will almost always have the best understanding of the program simply due knowing the logic and his/her thinking process while writing it.

I don't think that writing code can at all be compared to reading code in terms of ease of understanding. On one hand, simply writing software provides greater understanding of that specific piece of software due to knowledge of the context associated with each section of code, library used, etc. However, reading code that others have written can be difficult to understand in terms of the actual piece of software, but in terms of understanding the language it can provide insight into new ways of doing things or uses of a library that you might not have considered using, which can lead to making your life writing code easier.

In terms of build knowledge, I think reading code and writing code are very connected and in many ways build on each other. Experience writing code provides ease of understanding others code, and reading code allows you to have an easier time writing code (through new logic concepts, library use, etc).

Answer 7

This is something that I've personally felt to be self-evident, but I've never been entirely sure that it holds for the programming populace as a whole. For example, I've known some very talented coders who rather than read documentation, can happily pick through other people's code and comprehend it as if it were their own.

This leads to the question: does this matter?

If you're reading the code, then chances are you're making a change rather than rewriting it. Even if you are rewriting it, you're likely to be writing this in a new language/version and so you may not necessarily craft the code in the same way. The point I'm making is that it isn't always necessary to understand all of the code all of the time.

All this being true, newer development methodologies e.g. BDD do recognise that it is important for the business logic to be clear from the code rather than the code simply being a means to drive the machine. This of course is nothing new - the concept has been around since Donald Knuth's seminal work: Literate Programming.

Answer 8

I'm into StMotorSpark's answer, just adding:
It depends on so many factors it can't be a yes or no question, for instance:

• Is the existing code well documented and well written or does it look like a spaghetti without any sense or comments?
• Is it a tiny app with very rare situations that cost you endless time to find out how to solution, or a larger but simple app?
• etc.