Jonathan's Blog
name

Jonathan's Blog

Mindful Leadership and Technology


TagRebuild
Featured

Rebuild Application Rebuild Software Development

Code is Harder to Read than Write - Part 2 - More Reasons

Posted on .

Link to Part 1.

More reasons why code is harder to read than write:

  1. Code is meant to be executed by machines, not to be read by people. In other words, you, as a human, are not the intended audience. Everything about the program you're trying to read, including the intent of the language designers, was focused on machines and not on you.
  2. Developers don't get paid to write, they get paid to build.
  3. Developers prefer to build things over writing about it or adding comments to code.
  4. There is always a deadline. The deadline is never about writing comments or documentation.
Featured

Rebuild Application Rebuild Software Development Software

Code is Still Harder to Read than Write - Part 1

Posted on .

I've posted this article recently, but it got me thinking about why code is harder to read than to write. So, I will post it again, to make your life easier and explain why I think that code is still harder to read than write, even all these years later. Here's the article:

Things You Should Never Do, Part 1

The title of this post seems counter-intuitive because we think of reading and writing in relationship to human language, but programming languages are not like human language.

What are the important differences? Here is the main one:

Programming languages can't be read aloud.

So when we talk about 'reading code' we're using 'reading' in a purely metaphorical sense. When you 'read' code you don't actually read it - you're looking at it and trying to make sense of what it does.

This is nothing like reading a book, paragraph, or sentence written in human language.

When you review code you study, you re-read, you look things up. You jump around from file to file. You may consult web pages. Even in programming languages you are familiar with and with a business domain you know, these tasks can be time consuming.

You're trying to 'read' something that can't be read, across many files, and trying to ascertain the author's intent not just comprehend a sentence.

An equivalent would be trying to read in a language where you had to look up every third word, every time you read something because:

  1. Every author used the language in a novel way. AND
  2. Every page of a book was put in a different file and they were constantly referencing each other and not in order.

It would be hard. And it would not really be reading. That's what 'reading' code is.

Featured

Rebuild Application Rebuild Software Development Process

Application Rebuild Questionnaire

Posted on .

Here are some questions you should ask before starting a rewrite or rebuild of an existing software application.

This is a list to get you started. Once you have this information it is an important baseline for you to think about how to move forward on your rewrite/rebuild/re-engineering effort.

  1. What is the age of your application? (How long since the first line of code was written?)
    a. 0-5 years
    b. 6-10 years
    c. 11-15 years
    d. 16+ years

  2. How many integration points do you have with outside systems?
    a. 0 (lucky you!)
    b. 1-4
    c. 5-9
    d. 10+

  3. How many different types of people use the system?
    a. 1-4
    b. 5-9
    c. 10+

  4. Will you migrate data from the old system to the new?

  5. Roughly how many man-years have gone in to the development of the system?
    a. 0-10 years
    b. 11-20 years
    c. 20-40 years
    d. 40+ years

  6. What makes the current system great? What do your customers love? What differentiates you from your competitors?

  7. How much time needs to be spent recreating supplemental materials for a new system? Things that fall into this category - training programs, user manuals, help pages, websites, wikis.

  8. What are the business (not technical) drivers for recreating the system?

  9. What are the risks of recreating the system?

Featured

Rebuild Application Rebuild Software Development Process

The Age of Your Code

Posted on .

I recently posted this article (which is great) with lots of information about rebuilds:

Things You Should Never Do, Part 1

I reference it again, because it is great and it makes a lot of good points.

One thing it says is that 'Code Doesn't Age'. Specifically, Joel says this:

The idea that new code is better than old is patently absurd.

This is true in many senses: code doesn't get rusty, code doesn't wear out after the millionth time it's used, and you can make a thousand copies and this does not effect the code's quality in any way. Also, as he says, old code has been tested, where new code has not.

However, code can age, and I want to talk a bit about that and what it means to you. How can this ageless thing age? Here's how:

  1. Code Doesn't Stand Alone - unless you have a very, very simple program, it is connected to lots of libraries and (today) APIs. These things don't stay the same, nor are they supported forever. So, your code doesn't physically get old, but sometimes the things that it relies on break, or they get changed, or they are killed off. When this happens, your code just got old, very fast.
  2. Code Runs on Something - it used to be hardware, and deep inside of a data center somewhere that is still true. But even when we're only talking about VMs, VMs have operating systems and supporting code and those things aren't supported forever either.
  3. Code is Written by People - and people don't write COBOL anymore. Or at least most people don't. People also don't write VB or C++ as much as they used to. Sometimes perfectly good technologies fall out of favor and everyone learns something new making your product hard to support.

It used to be, most of what I'm describing happened over a long period of time. COBOL didn't go away overnight, that took decades. But with things being more and more interconnected via APIs, and with more changes coming quickly to platforms and other programs, the pace of change is increasing.

APIs change all the time, which is great (Hooray for new features and better performance!) and also challenging (I have to make the changes by when?).

Sometimes things come and go quickly or you make a bad choice. Silverlight anyone?

So, code doesn't physically age, but it is dependent on things around it. Those things can change or break. If that happens, the code has to be kept up or it has to be refactored or (sometimes) you need to rewrite an application entirely because the people who built the original are all retired.

The good news - you get to build something great with new technology that leverages all the awesome things your old project did, but is new and shiny and fun to code.

The bad news - all the things in that article are still true. So, you need to plan for them.

Featured

Rebuild Application Rebuild Software Development

Software Rewrite/ Rebuild/ Re-engineer

Posted on .

Oh no. Another rebuild article.

Oh, yes!

We're currently having some discussion about what to call this process (Rewrite? Rebuild? Re-engineer?) On the new Exadel website. I'm partial to Rebuild, but I think that Re-engineer is likely to win.

In my relentless pursuit of information on this topic, I'm compiling a list of articles related to it.

Read these before you start a project like this:

I have published #3 before, but it is definitely worth a second post.

Featured

Rebuild Application Rebuild Software Development

Application Rebuilds - A Micro-Service Approach

Posted on .

In some recent research I came across this post from Ben Martin:

http://www.ben-morris.com/refactoring-large-monoliths-to-microservices-strategies-risks-and-pragmatic-reality/

It's definitely something you should consider when considering your approach to an application rebuild. It has a high value for risk mitigation.

I will definitely put this in the bag of tricks for approach on rebuild projects. I can see a lot of situations where it would be valuable.

I can also see a lot of clients who won't go for it, but that doesn't mean it isn't useful.

Even ruling it out as an approach will have value to many projects. Offering it allows you to say it was there, but removed from consideration. This will help make it clear that the large, monolithic project approach (and related challenges) was explicitly selected.