Lure of coding.

Once you snap, you can’t.. live without? Update? Stay abreast?

The dream of doing software by snapping together nice libraries (components) is as old as the trade itself.

We’ll be looking at

• how does modularity in general change software development process
• how the NPM package repository and ‘npm’ tool helps JavaScript developers
• is the “Lego-land” approach to building software now a reality?

This article is a not a quick “5 steps to…” -type of article. Rather it’s about the philosophy of software development; the nature of solutions, and a bit of historical review for those who have not done coding in the 19xx’s.

Preface: Was software always modular?

No. Modules were kind of “invented”. In the truly old times, programs were a sequence of lines, executed by a computer as a linear sequence (batch processing – Wiki). Along the execution of a program, side effects did things like set values to variables. In the end, the variables were printed out on a printer paper or some kind of console. Typical use case: given parameters of a building project, calculate the cost estimates and print out a schedule for the project.

Then came two things:

• The User
• a need from the developer’s side to manage large programs

The User immediately brings “interactivity”: you can’t know what parts of your program get executed in which order. User navigates your software, triggers different kind of changes in it, and the user also does things you never knew was possible, or desirable. In the long run it’s quite a challenging job to balance the different user needs with keeping the program technically manageable and its usability high (software being easy to use).

The developer’s needs, on the other hand, have to do with the limits of our brain: seeing thousands of lines of linear but highly “spaghettized” code, characterized by jumps between chunks of the code, buried in IF…THEN cases, becomes a human headache. A computer never has a headache; sure, it can be slower to execute highly branched code, but the computer never “loses it”. We might.

Spaghetti code was difficult to debug, especially once a bug crept into the logic. Bugs are behavior of a software that is clearly against the specification. For example, if you get an “infinite” reading for a velocity of a real-world vehicle, you most liekly have some kind of bug in the software.

Side effects change the state of a program in abrupt manner, and the reality was that especially when handing over work from developer to another, things got really hectic. It probably took at least weeks or months for a newbie to familiarize with the “way of the program does things”. There’s quite scarce set of “by the book” -solutions to problems. Software engineering is inherently humane art, curiously, in that developers tend to easily roll their own solutions, once they get bored with looking for a perfect existing recipe. The more experience, vigilance and skills you have, more likely you are to be able to use well-known libraries and patterns. If you’re just beginning to do code, it’s inevitable that you’ll come up with exotic and rather backwardly solutions at first. And it’s completely ok — a necessary training part of becoming a good developer.

Next up, we’ll talk about batches, visit Object-oriented programming, and ponder on our ability to stand on the shoulders of giants. See you!