Explaining Why Development Takes So Long

It’s quite common for people who aren’t developers to complain about development time-frames. It’s hard to explain why it takes more than ten minutes to make a minor change like create a transition effect when it’s just a few clicks of a button to do this using PowerPoint.

Explaining that there’s extensive code in place in PowerPoint that makes the use of a transition effect simple is difficult without any context for the complainant, so I thought it might be fun to explore the concept of creating some pseudo-code with a hypothetical user to highlight how a task that seems simple can end up being a lot more complex. In this example, we will deal with the following development request:

I just need a simple change to my program to copy a file.

❗ Users often use words like just or simple, which instantly makes the request an effortless task for the developer :p

So lets make some pseudo-code (which is not real code, it’s just the steps that the programmer must create to write a program).

So, firstly we make a couple of variables, which is the file path of the file to copy and the file path of the destination. Then we’ll feed those into the copy command. Here’s our pseudo-code:

copy (source, destination).

Great! Job done, right? Wait, we need to make sure that program won’t error, so we need to do a few checks before copying the file. Lets check if the file exists before trying to copy it, because we can’t copy a file if it doesn’t exist – that’s a crash if left unhandled! Lets tell the user if it didn’t copy the file. Hmmm, it would be a bit reminiscent not to tell the user that the file successfully copied, otherwise the program wouldn’t look like it worked; so lets do that too.

if (file exists(source))
{
copy (source, destination)
Messagebox (“The file copy suceeded!”)
}
else
(
Messagebox (“The file copy failed because there was no file!”)
)

Cool, it’s looking good. Now we have a program that copies a file and won’t crash if the file doesn’t exist. Lets write some pseudo-code to make sure it doesn’t crash if there’s already a file in the destination. Hmmm, I suppose we’d better ask the user if they want to overwrite the file if it already exists, rather than just do nothing. Let’s do that!

if (file exists (source))
{
if (file exists (desintation))
{
Messagebox (“The file already exists. Do you want to overwrite it?”)
if (they want to overwrite it)
{
copy (source, destination)
Messagebox (“The file copy suceeded!”)
}
else
Messagebox (“The file copy failed because the file already exists and you didn’t want to overwrite it!”)
}
else
{
copy (source, destination)
Messagebox (“The file copy suceeded!”)
}
}
else
(
Messagebox (“The file copy failed because there was no file!”)
)

Great, now our program checks if a file exists, tries to copy it and gives the option to overwrite it if there is already a file where you’re trying to copy to. Is the file copy program complete? Well no, there are probably a few things we want to check to make sure the program doesn’t crash, like whether there is enough space to copy the file. I suppose we’ll have to get the size of the file and the drive to know that. Lets add that:

Check the size of the file
Check the free space on the drive
if (size of file > free space on drive)
{
Messagebox (“There’s not enough space on the drive to copy the file”)
}
else
{
if (file exists (source))
{
if (file exists (desintation))
{
Messagebox (“The file already exists. Do you want to overwrite it?”)
if (they want to overwrite it)
{
copy (source, destination)
Messagebox (“The file copy suceeded!”)
}
else
Messagebox (“The file copy failed because the file already exists and you didn’t want to overwrite it!”)
}
else
{
copy (source, destination)
Messagebox (“The file copy suceeded!”)
}
}
else
(
Messagebox (“The file copy failed because there was no file!”)
)
}

Hmmm what else might we need to do? Let’s check that the program has permission to copy the file – that means checking permission to read the source and write to the destination. It’s quite difficult to think about every possible scenario that might cause an error when copying the file, but we need to catch as many as possible so we can explain to the user why the program didn’t work instead of it just looking like it failed and the user not knowing why. That said, it’s not possible to think of everything, so we’ll also do a generic error catch if it doesn’t work. Let’s see what the code looks like with that in:

Check the size of the file
Check the free space on the drive
if (size of file > free space on drive)
{
Messagebox (“There’s not enough space on the drive to copy the file”)
}
else
Check permission to read source file
if (they don’t have read permission)
{
Messagebox (“No permission to read file”)
}
else
{
check permission to write to destination
if (they don’t have permission to write)
{
Messagebox (“No permission to write to file”)
}
else
{
{
if (file exists (source))
{
if (file exists (desintation))
{
Messagebox (“The file already exists. Do you want to overwrite it?”)
if (they want to overwrite it)
{
Try
{
copy (source, destination)
Messagebox (“The file copy suceeded!”)
}
catch unknown errors
{
Messagebox (“There was an unknown error”)
}
}
else
Messagebox (“The file copy failed because the file already exists and you didn’t want to overwrite it!”)
}
else
{
try
{
copy (source, destination)
Messagebox (“The file copy suceeded!”)
}
catch unknown errors
{
Messagebox (“There was an unknown error”)
}
}
}
else
(
Messagebox (“The file copy failed because there was no file!”)
)
}
}
}

Oh, I just forgot, the program also needs to take user input to decide which file to copy and where to copy it to, but only if it’s not in a config file! Here’s the code to append for that (I’m not going to bother with the code, lets just write a paragraph of things to do):

Try to open the config file
If the config file won’t open, ask the user for input of the source and destination
If the config file opened, read through it checking for the tag that specifies the source file path, then read the source file path and check that it’s a valid path otherwise pop up a message box saying that there was no valid source and ask the user to enter the source or cancel to fail the copy. Next read through the config file again looking for the tag specifying the destination file path, read the path and check it’s valid (otherwise pop up a messagebox saying that the destination was invalid and ask the user to specify one or cancel the whole thing)

Ok, I think now we have a program that simply copies a file without crashing. As you can see, something that is aactually one line of code to copy a file has turned into something that’s about 25 times bigger than the one line that does the copy. But of course the program isn’t finished because we also need to add options for giving the user the opportunity to retry the copy after they’ve corrected the issue that caused it to fail the first time, We also need to consider the ramifications of the file not being copied (does some other part of the program need to do something because the file didn’t copy?), maybe the program needs to automatically remedy some of the issues like cleaning up space on the drive or prompting the user for alternate credentials to read or copy the file. Maybe the user needs to verify the source and destination read from the config file, maybe there’s a timer that automatically kicks off the copy if they’ve not verified it manually within 10 seconds?

Additionally, now that we’ve added all this stuff, our psuedo-code has become messy, so we’ll have to tidy it up with a redesign. Why? Because there are so many nested bits of code, which can lead to increased difficulty reading and understanding what’s going on. This makes it harder to find out why the code doesn’t work if there’s a bug, and increases the complexity of making changes.

I won’t go into how this is done, because it’s beyond the scope of this and I’m getting bored (noticed I stopped doing the pseudo-code and just wrote a paragraph towards the end). However, I think this is a good example of how a simple request is not quite as simple as it seems – you can quite clearly see how one line of code to “simply copy a file” can easily turn into a hundred lines or more and have the potential for bugs that can cause a crash if not done properly.

Hopefully this helps explain why your developer groans when you say “Can you just…” followed by more groaning when you ask why it will take so long 🙂

Finally, as you can see from this, adding time pressure will cause the developer to deliver a buggy product that can crash. Thanks for taking the time to read.