DEV Community: Rares Portan

Using fetch

Rares Portan — Sat, 01 Aug 2020 14:21:18 +0000

For years, the default way to call APIs from a web page was XMLHttpRequest. But working with XMLHttpRequest was not easy, so on top of it were build lots of popular libraries like jQuery.ajax() or Axios who wrapped the XMLHttpRequest functionality in a Promise based interface and also hiding away its complexities.

These days browsers provide a better alternative to XMLHttpRequest: fetch(). Recently I migrated some code that used Axios to fetch. I was surprised by how hard that was.

Fetch has a few gotchas that we all should know about before we start using it, but using a native browser feature, should be preferred over a library, even for the simple fact that you can get rid of a few 3rd party kilobytes of JavaScript.

A simple example

// the only required parameter is the URL
fetch('http://api.open-notify.org/astros.json') 
    .then(response => {
        // do something with the response
    })
    .catch(error => {
        // do something with the error
    });

Fetch function returns a Promise.
A Promise can be:

resolved when it is successful (in this case when the response from the server is received )
rejected when it fails (in this case when the response from the server cannot be received)

Since the Promise is resolved/rejected at a later time, asynchronously, we need to register callback functions:

then is called when the promise is successful
catch is called when the promise fails

Or if you prefer async / await, you can use that too:

try {
    const response = await fetch(url) 
    // do something with the response
}
catch(err) {
    // do something with the error
}

But any useful fetch() is a bit more complicated.
The response of a fetch() request is a stream, so depending on the type of data returned by the server, you need to get the data from the stream.

For example, if the server response is JSON, you need to call response.json() that returns a Promise that resolves with the result of parsing the body text as JSON.

fetch('http://api.open-notify.org/astros.json') 
    .then(response => response.json() // or .text(), .blob(), .arrayBuffer(), .formData()
    .then(data => {
        // do something with data    
    })
    .catch(error => {
        // do something with the error
    });

We can use fetch() to load all kind of data, like image files, audio or video files:

fetch('/image.jpg')
    .then(response => response.blob()) // returns promise
    .then(blob => {
        image.src = URL.createObjectURL(blob);
    })
    .catch(error => {
        // do something with the error
    });

How to handle errors

Now here is something unexpected. Here is it, straight from MDN:

The Promise returned from fetch() won’t reject on HTTP error status even if the response is an HTTP 404 or 500. Instead, it will resolve normally (with ok status set to false), and it will only reject on network failure or if anything prevented the request from completing.

I have no idea why it's working like this, none of the alternatives work this way, but this happens when you fetch an URL and the server responds with a 4xx or 5xx error:

fetch(url) 
    .then(response => {
        // This code is executed even for 4xx-5xx errors!
        // But the response will not contain expected data!
    })
    .catch(error => {
        // This is not called for 4xx-5xx errors!
    });

We need to detect these errors and handle them. The response has an ok flag that is set to false when the server responds with an error, so we can use that flag:

fetch(url) 
    .then(response => {
        if(!response.ok) { 
            const error = new Error(response.statusText || 'Fetch failed') 
            error.response = response;
            throw error; 
        } 
        return response; 
    }) 
    .then(response => response.json() // this is skipped for 4xx-5xx errors!
    .catch(error => {
        // this is now called for 4xx-5xx errors!
    });

We can extract error related code in a separate function so we can use it with multiple fetch calls:

function checkForErrors(response) {
    if(!response.ok) { // 
        const error = new Error(response.statusText || 'Fetch failed') 
        error.response = response;
        throw error; // or Promise.reject(error)
    } 
    return response;
}

fetch(url) 
    .then(checkForErrors) 
    .then(response => response.json() // this is skipped for 4xx-5xx errors!
    .catch(error => {
        // this is now called for 4xx-5xx errors!
    });

Advanced usage

Besides the URL, fetch accepts an object with different options

fetch(url, options) 
    .then(response => {})
    .catch(error => {});

Here they are (those with * in front are the default values)

{
    method: 'POST', // *GET, POST, PUT, DELETE, etc.
    mode: 'cors', // no-cors, *cors, same-origin
    cache: 'no-cache', // *default, no-cache, reload, force-cache, only-if-cached
    credentials: 'same-origin', // include, *same-origin, omit
    headers: {
      'Content-Type': 'application/json' // 'application/x-www-form-urlencoded', multipart/form-data, text/plain
    },
    redirect: 'follow', // manual, *follow, error
    referrerPolicy: 'no-referrer', // no-referrer, *no-referrer-when-downgrade, origin, origin-when-cross-origin, same-origin, strict-origin, strict-origin-when-cross-origin, unsafe-url
    body: JSON.stringify(data) // body data type must match "Content-Type" header
  }

This means the following are the same:

fetch(url) 
    .then(response => {})
    .catch(error => {});

fetch(url, {
        method: 'GET',
        mode: 'cors', 
        cache: 'default', 
        credentials: 'same-origin', 
        headers: {
            'Content-Type': 'application/json'
        },
        redirect: 'follow', 
        referrerPolicy: 'no-referrer-when-downgrade', 
        body: ''
    }) 
    .then(response => {})
    .catch(error => {});

Let's dive into some of the options and see how we can use them.

method option

By default fetch() will make a GET request.
If you want to do a POST you'll need to set the method option to POST. Usually, you'll also send some data:

const data = { user: 'Jon', city: 'London'}

fetch(url, 
    {  
        method : 'POST'  
        headers: { 
            'Content-Type': 'application/json', 
        },
        body: JSON.stringify(data), 
    }) 
    .then(response => {})
    .catch(error => {});

mode option

The fetch mode can be cors, no-cors, or same-time.

fetch(url, 
    {  
       mode: 'cors'
    }) 
    .then(response => {})
    .catch(error => {});

CORS headers are used by some servers to accept requests only from certain domains (e.g. company.com doesn't accept requests from others.com)
By default, the cors mode is used by fetch. This means that if the server doesn't have the CORS headers set correctly, the fetch will be canceled. These are the most frustrating errors I ever encountered.

credentials option

To access some resources on some servers you need to authorized, e.g. to read your Gmail you need to be logged in with your Google credentials.

You are asked to log in once, and any subsequent fetch requests made by your browsers are allowed if your requests include the credentials.

fetch(url, 
    {  
       credentials: 'include'
    }) 
    .then(response => {})
    .catch(error => {});

Usually, credentials are saved as cookies, and thus when you use credentials include, all cookies are sent to the server. And this can sometimes create problems, as some servers accept
only a limited length of cookies.

Timeout

Sadly fetch() doesn't provide out-of-the-box support for timeouts. This means that the fetch request will wait forever for the server to respond.

Luckily we can implement this by wrapping the fetch in a Promise that we can resolve or reject:

// create a wrapper
function fetchTimeout(url, options, timeout = 5000)
    // return the promise
    return new Promise(resolve, reject) {

        const timer = setTimeout(() => {
            reject(new Error('Request timed out'));
        }, timeout);

        const clearTimer = response => {
            clearTimout(timer);
            return response;
        }

        fetch(url, options)
            .then(clearTimer) // clear the timer
            .then(resolve)
            .catch(reject);
    }
}

// use the wrapper instead of fetch
fetchTimeout(url, {}, 10000) 
    .then(response => response.json() 
    .then(data => {
        // do something with data    
    })
    .catch(error => {
        // do something with the error
    });

Cancel

Sometimes we want to cancel a fetch().

Let's assume you are on Youtube or Netflix, you fetch a video but then you change your mind and want to see another video. You start fetching the new one, but what happens with the other one? You don't want to see it anymore so you want to cancel it. How you do that?

Well, you can use AbortController, a shiny new experimental technology! (FYI It's already available in all major browsers)

// create a controller
const controller = new AbortController();
const { signal } = controller;

// call abort() if you want to cancel it
controller.abort();

Here is how you can use it with fetch, you pass the signal as an option:

const controller = new AbortController();
const { signal } = controller;

fetch(url, 
    { 
        signal  
    })
    .then(response => {})
    .catch(error => {
        if (error.name === 'AbortError') { 
            console.log('Fetch aborted');
        } else {
            // error not caused by abort
        }
    });


// Abort request
controller.abort();

If you pass the same signal to multiple fetch calls, controller.abort() will cancel all requests with that signal.

If you call .abort() after the fetch has completed, nothing happens, abort is ignored.

It took a long time for the Abort API to be accepted:

The key disagreement is one group wanted the abort method to exist on the object returned by fetch(), whereas the other wanted a separation between getting the response and affecting the response. -- Jake Archibald

I would prefer the object returned by fetch() to have the abort method. Since is best to keep the abort details hidden we would need to create a wrapper like this:

function abortableFetch(request, opts) {
  const controller = new AbortController();
  const signal = controller.signal;

  return {
    abort: () => controller.abort(),
    ready: fetch(request, { ...opts, signal })
  };
}

Because the above solution breaks the interface of the object returned by fetch(), we could add the abort() on that object (e.g. as proposed by the group that lost)

function abortableFetch(url, options) {
    const controller = new AbortController();
    const signal = controller.signal;

    // return the promise
    const promise = new Promise(resolve, reject) {
        fetch(url, {...options, signal)
            .then(resolve)
            .catch(reject);
    }
    promise.abort = () => controller.abort();

    return promise;
}

This allows us to combine the timeout and cancel functionality in a single wrapper:


/**
 * Fetch that can timeout and is cancellable
 */
function enhancedFetch(url, options, timeout = 5000) {
    const controller = new AbortController();
    const signal = controller.signal;

    const timer = setTimeout(() => {
        reject(new Error('Request timed out'));
    }, timeout);

    const clearTimer = response => {
        clearTimout(timer);
        return response;
    }

    // return the promise
    const promise = new Promise(resolve, reject) {
        fetch(url, {...options, signal)
            .then(clearTimer) // clear the timer
            .then(resolve)
            .catch(reject);
    }
    promise.abort = () => controller.abort();

    return promise;
}

Progress

We can track the download progress (but not upload progress) using response.body, that is a ReadableStream, a source of data, from which we can read data as it becomes available.

Unlike response.json() and other methods, response.body gives full control over the reading process, and we can see how much data is received at any moment.

const progressIndicator = (length, total) => {...}

fetch('https://reqres.in/api/users/1') 
    .then(response => {
        // get reader from response body
        const reader = response.body.getReader();
        // get total length
        const contentLength = +response.headers.get('Content-Length');
        let receivedLength = 0; 
        let chunks = []; 

        while(true) {
            const { done, value } = await reader.read();

            if (done) {
                break;
            }

            chunks.push(value);
            receivedLength += value.length;
            console.log(`Received ${receivedLength} of ${contentLength}`);
            // here you can call a function with the current length
            progressIndicator(receivedLength, contentLength)
        }

        // when all data is available it's time to parse it
        let contentArray = new Uint8Array(receivedLength); 
        let position = 0;
        for(let chunk of chunks) {
            contentArray.set(chunk, position); 
            position += chunk.length;
        }
        // decode content array into a string
        const result = new TextDecoder("utf-8").decode(contentArray);
        // finally get data
        const data = JSON.parse(result);
    })
    .catch(error => {});

Polyfill

All major browsers support fetch these days, but if you want support for IE11 or some other old browser, you'll need to use a polyfill (like https://github.com/github/fetch)

Resources

Thanks for reading. This article was originally posted on my blog.
Cover Photo by K. Mitch Hodge on Unsplash

How to Get 100 Website Performance Score

Rares Portan — Tue, 07 Jul 2020 06:33:45 +0000

First, let’s see what 100 website performance score means. A tool, called Lighthouse, is used to measure website performance. The measurement is a score between 0 and 100. 100 means the best performance.

This score is important in several ways:

It’s an indicator of the user experience. If the website is slow, visitors will not wait and move on to other sites. This is even more important on mobile devices, which in general have a slow internet connection.
It’s part of the Google Search Engine algorithm that determines the rank of the website for a search query. The lower the score, the lower the website ranking, given there are other sites that match the search query and have a better score.

Lighthouse is integrated into Chrome’s Developer Tools so you can use it from there, but you should use web.dev or PageSpeed Insights because the DevTool's score is influenced by Chrome plugins you have installed.

The tips presented here can be applied to any website, but as an example I'll use my website, https://www.raresportan.com.

Here is the performance score of my website using web.dev:

The performance score is determined by 3 metrics:

Largest Contentful Paint (LCP): measures loading performance. To provide good user experience, LCP should occur within 2.5 seconds of when the page first starts loading.
First Input Delay (FID): measures interactivity. To provide good user experience, pages should have an FID of less than 100 milliseconds.
Cumulative Layout Shift (CLS): measures visual stability. To provide good user experience, pages should maintain a CLS of less than 0.1.

Why Go for 100?

A score of 90+ is great, you are doing a great job. So why would someone want to go for 100?

There is no good answer to this question. There’s not much of a difference between 90+ and 100 scores. People will have the same experience. The rank on Google will be the same. You’ll go for 100 only if you want to demonstrate that you can. That you go the extra mile. This is why I did it anyway.

Why you should not go for it? If your website is very interactive, fetches data, uses buttons to post data, so is very dynamic, you’ll have a hard time reaching 100 because you’ll need to load too much JavaScript.

How to Do It

This can be done by removing a lot of JavaScript, embedding CSS and fonts and using less images and optimizing the images.

1. Remove Javascript

JavaScript affects LCP & FID.

I’m using Gatsby to build the website, the pages are rendered server-side and served as HTML to the browser. But after the HTML is loaded, it also loads 200k of JavaScript, including React. When React loads it adds interactivity to your buttons, fetches data, etc.

Because the website has mostly links, few buttons, no data fetch, I removed all the JavaScript added by Gatsby using the gatsby-plugin-no-javascript in gatsby-config.js

module.exports = {
  plugins: [
      ...
      `gatsby-plugin-no-javascript` ]
}

I have a button the website, the lightbulb next to the site name is used to change the theme. That was not working anymore after I’ve removed all the JavaScript, but I’ve solved this by reimplementing the functionality in plainJavaScript inside html.js:

 <script
    dangerouslySetInnerHTML={{
    __html: `
        var theme;
        try {
            theme = localStorage.getItem('theme');
        } catch (err) { }

        if(!theme && window.matchMedia('(prefers-color-scheme: dark)') && window.matchMedia('(prefers-color-scheme: dark)').matches) {                
            theme = 'dark'
        }               
        document.body.className = theme || 'light';

        function toggleTheme() {
            var body = document.querySelector('body');
            var newTheme = body.className === 'dark' ? 'light' : 'dark';                
            body.className = newTheme;
            try {
                localStorage.setItem('theme', newTheme);
            } catch (err) { }
        }`
    }}
/>

Another thing that I did was to call the analytics function from html.js also, this way I don’t include Google Analytics scripts on the website:

<script
    dangerouslySetInnerHTML={{
    __html: `
        // send analytics data
        function sendData() {
            var sitedata = {
                ...
            }
            return fetch('/.netlify/functions/send', {
                body: JSON.stringify(sitedata),
                method: 'POST'
            })
        }
        sendData();
    `
    }}
 />

If you are using Twitter share on your website you might need to remove the Twitter library and replace the calls with plain links. Here is an example:

<a href="https://twitter.com/share?url=https://raresportan.com/how-to-get-100-performance/&amp;text=How%20to%20Get%20100%20Website%20Performance&amp;via=raresportan" 
   target="_blank" 
   rel="noreferrer">
    Please share it with your friends on Twitter    
</a>

2. Embed Critical Styles

CSS files affect CLS. If the CSS is loaded after the HTML is rendered, the page visuals are changing.

Critical CSS must be added inside the HTML using a <style> tag. Do not use a .css file for your critical CSS.Lucky me, Gatsby does this by default. It concatenates the content of all CSS files in a single string that is added as <style> tag inside the HTML.

3. Embed Fonts

Just as CSS, fonts affect CLS. The moment the font is loaded, the texts on the page are re-rendered. And just as CSS, the fonts must be in the HTML, and not loaded as separate files.

In my case, I creates a fonts.css that contains the font sources as base64 encoded strings. They end up inside the<style> tag with the rest of the CSS.

@font-face {
    font-family: IBM Plex Sans;
    font-style: normal;
    font-display: swap;
    font-weight: 500;
    src: url(data:font/woff2;base64,d09GMgABAAAAAEjQABEAAAAAy...)

I used a base64 command (available on macOS and Linux) to transform the fonts:

$ base64 myfont.ttf > fontbase64.txt

Alternatively, you can use an online service to do this.

4. Optimize Images

You should use few images if possible. If not make sure you optimize the hell out of them.Always set a width and height or put them inside a container that has ‘overflow: hidden’, otherwise when an image is loaded it moved content around and this is very bad for the CLS.

I’m using Gatsby’s plugins to optimize my images. It automatically generates different images for different viewport sizes and loads the images lazy:

<img class="gatsby-resp-image-image" 
    alt="The performance score of this website" 
    title="The performance score of this website" 
    src="/static/772422e4c6077575d4fc47afd461bf7e/c5bb3/perf.png" 
    srcset="/static/772422e4c6077575d4fc47afd461bf7e/04472/perf.png 170w,
            /static/772422e4c6077575d4fc47afd461bf7e/9f933/perf.png 340w,
            /static/772422e4c6077575d4fc47afd461bf7e/c5bb3/perf.png 680w,
            /static/772422e4c6077575d4fc47afd461bf7e/b12f7/perf.png 1020w,
            /static/772422e4c6077575d4fc47afd461bf7e/b5a09/perf.png 1360w,
            /static/772422e4c6077575d4fc47afd461bf7e/eee07/perf.png 1628w" 
            sizes="(max-width: 680px) 100vw, 680px" 
            loading="lazy" 
            style="width: 100%; height: 100%; margin: 0px; vertical-align: middle; position: absolute; top: 0px; left: 0px;">

Beside this I’m using a Netlify plugin that optimizes the image even further.

5. Preload Pages

One of the nice things Gatsby does is that it preloads all the pages referenced by a specific page. And thus navigation from one website page to another is instant.

I loved that. But now that I’ve removed JavaScript, the navigation between pages is much slower.I almost give up at this point. While the initial page load was faster, the in-site navigation was worse.

In the end, I wrote a bit of plain JavaScript that prefetch a page when the user hovers on the link. With this I save 100-300ms and the page are appearing to load faster:

<script
    dangerouslySetInnerHTML={{
    __html: `
        window.addEventListener('DOMContentLoaded', (event) => {
            document.querySelector('button.lightbulb').addEventListener('click', toggleTheme);

            //only in-site links
            var links = document.querySelectorAll('a[href^="/"')
            links.forEach(function(link) {
                link.addEventListener('mouseover', function(e) {
                var l = e.target;
                var href = l.href; 
                var link = document.querySelector('link[href="'+href+'"]');
                if (!link) {
                    var prefetchLink = document.createElement("link");
                    prefetchLink.href = href;
                    prefetchLink.rel = "prefetch";
                    document.head.appendChild(prefetchLink);
                }
            })
        });        
    `,
    }}
/>

Conclusion

If you are willing to make some compromises, most importantly to replace kilos of JavaScript libraries with some vanilla JavaScript you can reach a 100 score in website performance.

While you can do something about CSS and fonts, in most cases is probably not practical to remove all the JavaScript, and a 90+ score is fine.

Thanks for reading. This article was originally posted on my blog.
Cover Photo by ShareGrid on Unsplash

What Makes Good Code Good

Rares Portan — Fri, 12 Jun 2020 07:00:50 +0000

There are things that make or break software, like good User Experience Design, marketing that should come up with the right features for the right app, or management that should pick up the right people for the right job.

Those things might be out of your control. What you can control is the other important part: designing and writing the code.

So the question is: What is good code? What should you look for? Ask ten people and you’ll get ten different answers. Read ten books and you’ll find ten different answers. Different people, different experiences, different problems, different contexts, different answers.

Truth is there is no good answer. Context matters, timeframe matters, money matters.

How can we describe good code

But no matter the situation or context, good code has a few evergreen qualities:

Simple

The code is simple to understand, simple to modify, untangled, decoupled, obvious. This means the code is not complex, not tangled, not coupled, not spaghetti.

Simple code doesn’t cause side effects outside of its scope
and cannot be influenced by outside scopes. A classic example: if the code receives a mutable object as input, it will not change the object causing outside side effects, and any change to the object will not change the state of the code.

But beware, simple does not necessarily mean easy or familiar.

Clear

Clarity of code means clarity of purpose. The code must tell what it’s doing at every level. There should be no obfuscations, no hidden things, no mess. It's clear in which state it is. It's clear if something is wrong. It's clear if it can’t complete its task or if it is waiting for something.
Everything happens for a reason, and the reason should be clear.

This is maybe the hardest thing to get right. Thousands of small or big decisions are taken in the lifetime of a codebase. And those decisions are lost. The whys are lost.

Reliable

Works in the same way no matter the conditions or context. It is hard to be used in incorrect ways, hard to break. When incorrect input is used, the software clearly indicates why the input is wrong and what to use instead. It doesn’t return references to the inner state.

This is the edge functional languages have over the object-oriented ones. Coding with immutable data is the most efficient way to create reliable code.

Efficient

It is designed to be as fast as possible. It is designed to consume as little memory as possible.Everybody heard that “premature optimisation is the root of all evil”. This quote was perverted in all possible ways as an excuse for slow and inefficient software. Just remember this: At the function level, you can always optimise later. But at higher design levels, you must plan for performance.

You must think not only about the data flow but also about the flow rate. If the design is bad, expect a laggy app.

Composable

It means your code is built like everything else around you. Look around, you can always find a hierarchy, smaller things are combined to create greater things. By understanding the hierarchical structure of things, you can understand the roles each component plays and how they fit into the larger picture.

Good code creates big systems from smaller ones, which are built from even smaller components.

Balance, compromise, and trade-offs

Usually, some of these qualities are at odds with others.

The clearest code might not be the fastest one. Most reliable code might not be the simplest. You need to find the right balance between them, depending on context and the problem you try to solve.

First aim to make the code clear and simple. Then modify it to make it more reliable and efficient, giving up on some of the clarity and simplicity.

Easy to use almost mandates garbage collection, but that collides with ‘fast’ and ‘simple to implement’. Removing pointers makes the language safer, but at a steep loss of generality. Trying to make pointers safe with a ton of language rules makes the language hard to use. I could go on. - Bert Hubert

Why don’t people code like that?

This question has always intrigued me. Everybody likes to brag with their skills and knowledge and the awesome languages or tools they use. But somehow they make poor code. The answer is simple: it is easy to write bad code and quite hard to write good code.

At some point, somebody made these observations about code implementations:

CODE	IMPLEMENTATION
Appears to work	Easy
Correct	Far more difficult
Can be understood by others	Very difficult
Can be modified in the future	Very very difficult
Efficient	Very very very difficult

Most of the code is at the “appears to work” level. Some of it is “correct” and “can be understood by others.” Almost none “can be modified in the future” with the confidence that changes will not break something.This happens because people stop iterating on the code too soon. They think they are done when they are not.

Everything, code and design, must be an iterative process.
Software is never written, is always rewritten.

What you can do as a programmer, though, is get through the assignments doing something that works, and then look back at it and see how you could have made it better or faster or more concise. This is one thing that seriously differentiates programmers from excellent programmers. - Brian “Beej” Hall

Simple vs. easy

While most of the qualities of good code are obvious, one is not.
People often don’t understand what simple code means. Many people think simple means easy.

This is not true. Simple means something that works with one thing at a time or does one thing at a time.

SIMPLE CODE	EASY CODE
One purpose	Many purposes
Values	Objects
Data	Classes
Map/Reduce/Filter	Imperative loops
Pure function	Method mutating state
Function that does a thing	Add an “if” in a function
Object using object	Class extending class
Consistency	Inconsistency
Implement yourself	Download it from the Internet

See Rich Hickey's illuminating presentation.

Trade-offs of doing simple code

SIMPLE CODE vs. EASY CODE
Development starts slow vs. fast
Development speed grows to a level vs. slows down forever
Development speed remains constant vs. is near zero

Simple code implies a slow start. Doing easy code, you get fast initial development time but it slows down constantly. At some point, after you have enough code, the development speed is near zero.

For simple code, you get slow initial development time but it grows and remains at a constant level.Simple code requires more effort and discipline. You have to think more, you have to resist the easy way.

Simple code is underrated and unappreciated. Usually, nobody notices it, but when they notice it they are not happy about it:

Developers don’t notice it because it doesn’t get in their way.
Teachers don’t like it because they think it is too mundane and below their level of intelligence.
Consultants and methodologists don’t like it because they can’t ask a ton of money for something simple.
Managers don’t like it because they think you waste too much time on trivial things. “What? You spent days thinking about this simple and obvious code? A novice would have done it in 5 minutes”

Still, there is nothing more sophisticated than simple code.

The parable of two programmers

A while ago, two companies, the Automated Co. and the Consolidated Co. decided that they need the same program. Here is how they handled the problem.

Day 1

Automated hires a very expensive consultant, Alan, to solve their problem.

Consolidated decides to let one of their bright programmers, Charles, to do the job.

Day 10

At Automated, Alan, with a long experience in difficult programming projects, decides to use a well-established design methodology. He asks for three more programmers. The team goes to work, making preliminary analyses, UML diagrams, meetings, Excel spreadsheets.

At Consolidated, Charles spends time thinking about the problem.
He often sits with his feet on the desk, scribbling on paper and drinking coffee.

Day 30

At Automated, the team is starting to write code. The programmers are spending about half their time writing and building code, and the rest of their time in the conference, discussing the interfaces between the various modules. They finally release an implementation schedule. In two months they will have a test version of the program. In four months they will have the gold version.

Meanwhile, at Consolidated, Charles is busy coding.

Day 90

At Automated, the team has completed two of the four major modules required for their program. These modules are now under testing while the other modules are finished. When tested it seems to satisfy most of the original specifications.
It has omitted one or two features and is very fussy about the format of its input data. However, the company decides to go with the program. They can always train their data-entry staff to enter data in the strict format required. The program is handed over to some maintenance programmers to eventually incorporate the missing features.

Charles completes the project at Consolidated. When tested, the program does everything required in the specifications. Except for some quickly corrected oversights, it performs well. It even has a few additional convenience features which might significantly improve the usability of the program.

Aftermath

Alan was complimented for completing his project on schedule.
His manager at Automated looked over the program. He saw that the company standards were present. He quickly gave up attempting to read the program however; it seemed quite incomprehensible. He was convinced the project was really much more complex than he had originally assumed. Alan was given a hefty pay raise and promoted as a reward for his achievement.

At first Charles’ manager at Consolidated was impressed. But as he read through the source code, seeing how simple it was, he was convinced that the project was really much simpler than he had originally thought. It seemed that this was not much of a challenge. At his next salary review, Charles was given a small raise. He was not given a promotion. After about a year he left the company.

(An adaptation of The Parable of the Two Programmers)

Who you are?

Alan, who writes code that only he understands, but thus securing his job. Or Charles, who writes simple code, but is not appreciated because of this. I'll always be a Charles. Maybe just because the world is full of Alans.

Thanks for reading. This article was originally posted on my blog.
Cover Photo by Irvan Smith on Unsplash