9 Easily Digestible Concepts in Software

Sometimes software engineers use terms that just don‘t make sense to us. Let‘s cut out that

gobbledygook and see what it‘s about!

YOU KNOW, WITHOUT DEPRIVING TURKEYS OF THEIR VOCABULARY AND ALL.

And since I love explaining with food, we‘re seeing the 9 in terms that have to do with food or drink.

1. Interface, Front End, Back End You know how you walk into a restaurant and you see something like this?

―LA FROU-FROU SPAGHETTI‖

That is so all about presentation. You certainly don‘t get to see what‘s really going on behind

the scenes, which is often something more along the lines of the chef having a melt-down.

(AND ER, EXPLAINING HOW HE CUT HIS FINGER WHILE COOKING)

And there‘s the difference between the front and back end of an application. The pretty dish

maps to the GUI and all the screens that the user would actually see, while the back end is the

steaming, sweating code that labors to make the screens actually happen. Interface is just

another word for front end, so you‘re covered.

2. Cache A cache is just a memory stash. You store data in a cache so that you can later ask for that

data and get it more quickly. It‘s sort of like a water purifier funda. You don‘t pour just enough

water into your purifier to fill a bottle. You get as much clean water processed as you can, so

that when you need to fill a bottle later, there‘s enough water and you don‘t have to wait.

SO A REGULAR PC IS LIKE A WATER PURIFIER (IT CAN STORE), BUT IPAD IS BASICALLY ZEROB (INSTANT SUPPLY ONLY).

3. Classes, Functions, Objects, Instances Possibly one of the nerdiest points on this list, I guarantee you will get paisa vasool for knowing

this one. Basically since this multi-level concept is the foundation of so much of programming

itself that software designers tend to replicate this idea even in the way they expect users to

interact with the software they design.

Classes Classes are abstractions of a concept. They contain all the actions and things associated with

the concept. For instance, a class called ‗Time‘ may contain all the actions and things

associated with time. But where‘s the food in all this you ask?

CLASS: BAKERY

I trust I have your attention again. Think of the class ‗Bakery‘. It contains the functions and

objects associated with bakery.

Functions Functions are action-oriented. They do things. So in our Bakery class, we have a function called

‗whisking_Eggs‘.

GETTIN‘ ALL HOPEFUL ABOUT WHERE THIS IS LEADING, AINTCHA!

Objects When you‘re busy doing funky stuff, you need things to perform the actions on, right? Enter

‗objects‘. My function ‗whisking_Eggs‘ is acting on an object called…Eggs. Eggs sound like good

constants, so let‘s assume they are. Objects can be constants, variables or even other

functions. That means ‗whisking_Eggs‘ can even act on ‗mix_CakeBatter‘, which is another

function in the Bakery class.

WE ALL KNOW ONLY GOOD CAN COME OF THIS.

Instances Now when I say ‗Eggs‘ is an object, there are still various attributes ‗Eggs‘ could possess.

White, brown, multi-coloured? Large, small, rotten, organic … You get the picture. In

programming, when I assign one of these possible attributes to an object, I create an ‗instance‘

of the object. ‗Egg-that-is-brown-and-large‘ is an instance of ‗Eggs‘.

GO ON, TAKE IT. I DARE YOU.

So in software terms, typically when you‘re filling in a feedback form for someone off your

company portal, you‘re modifying an instance of the form and saving that. You‘re not actually

changing the form itself, because only the portal admin can do that.

And so there you have it. Classes, functions, objects, and instances: easy-peasy.

4. Constants, variables and parameters You must‘ve heard the terms above, along with string, int and so on, right? (Hint: correct

answer-yes!)

What are they all vaguely associated with?

THAT.

All of ‗em are different kinds of containers for data values. Constants refer to containers that

have a fixed or ‗constant‘ value (doh) across the code. Variables refer to containers whose

value can keep …

…Varying!

So what are parameters? You know that function we talked about earlier in the 3rd item of this

list? – It‘s still whisking eggs! Software engineers are compassionate: they set parameters to

define the boundaries of the action of the function. Whisk eggs for 10 minutes. The duration of

whisking is a parameter.

In case you got suspicious at this point and felt diddled out of a satisfactorily food-oriented

explanation (you greedy thing!), here‘s a summary:

What does an egg cup contain? – only eggs, so it‘s a constant.

What does a wooden bowl contain? – could be any number of things, so it‘s a variable.

What does an egg timer do? – Sets the limit for an action, such as the time for which an egg

should be boiled, so it‘s a parameter.

5. Waterfall, Agile and Scrum (Methods of Development) Jamie-san, Mr. Miyagi cannot protect you from all evils. These are undoubtedly software-sy

concepts, and finding a food parallel is rather hard. But see if this works for you:

On Master Chef, you sometimes have, say, 9 contestants, and they have to team up and work

together on a challenge, right? Each team has a leader. Meet the leaders:

UNLIKE THE EARLIER DUDE, THESE ONES ARE JUST POSING. NO CUT FINGERS... YET!

Each of these chefs has a distinct way of working.

The Waterfall Chef

This woman is a bit old-school. One-thing-at-a-time-finish-it-then-move-on-

never-look-back. She tells her team to work sequentially, starting at

appetizer and moving on from there. She just cannot afford mistakes or

rework – imagine getting a redone mushroom tikka in the middle of eating a

soufflé?! Her strategy isn‘t awesome (doh) but it‘s very clear-cut to explain,

and in that way, has great appeal to the restaurants that hire her, or the

other chefs she‘s considering employing.

The Agile Chef

Apart from posing madly, this dude likes to follow a cyclic pattern of work—see

how it goes—work some more. So say he has an hour to prepare dinner. He‘s going

to first tell his team to make roti subji (I hear your disappointment). Then he‘ll

take a time check. Then since there‘s ample time, he‘ll ask his team to make the

subji fancier or even make another one. Time check again. He‘ll then decide to

instruct side-drink and desert preparation. His customers are getting quite a few deliveries.

Each delivery is an improved version of the meal, but the essentials have already been planned

and served right at the start.

The Scrum Chef

To look that happy despite being landed with a title like ‗Scrum‘, this man‘s

probably inventing a bizarre dish like Bhaang-kok Chicken! Anyway, he‘s

remarkably similar to the Agile chef (because Scrum is a variant of Agile

methodology), and just uses some variations like appointing each person in

his team to ‗own‘ a dish. So in his kitchen, people meet regularly to discuss

what they‘re going to do, and they rely heavily on continuous information

sharing to figure out how they‘re performing as a team.

Whew. We labored through that one. I think a summary is in order:

6. Thin and Fat Clients Now this is a bit like the difference between a drive-through and dine-in restaurant, the focus

not being on the client (like in ―customer‖), but on the application-as-the-service.

Drive-through: This is the one that‘s like a thin client. It‘s quick

service, you are totally unaware of the action and actual

work going on behind the scenes, all you see is what‘s

being chugged out to you super quickly through the

interface. The interface is all you‘re interacting with,

and in your mind, the interface is all that exists.

In the software scene, it‘s almost like you‘ve only

installed the front-end – the heavy database and so forth are not on your machine. It‘s all

tucked away out of sight on some hard-working server (kitchen) that‘s busy catering to

requests passed on through the interface (order window). It‘s got its perks, but hey, can you

ever walk into a drive-through or order a ten-course meal? Certainly not, so it‘s good but not

meant for heavy-duty, huge requests.

Dine-in: (I know, it‘s more like they‘re saying ―LAME!‖ rather

than ―Cheese!‖, but bear with me.)

The dine-in is a clunkier concept than a drive-

through if you think of all the infrastructure needed.

You get glimpses of the guys clearing away your

dishes, bringing your food, and of the ones in the

kitchen. But the thing is, with a dine-in you can go

to town on what you‘re ordering and you can take a

party of 15 with ya. So this, in the software world, is called a ―thick‖ or ―fat‖ client, but it aint

no slob! This is the real deal, capable of powerful delivery and heavy work.

7. Enterprise Applications and… Jyaada Lafda Nahee Applications Don‘t be knocked flat by my sudden hindi skillz: that‘s what my manager calls the second kind,

and it‘s a perfect description. Enterprise apps are ginormous sprawling beasts, which involve

work flows and roles and different features for different roles and all of that jazz.

The other kind of applications, which don‘t have a special name, are like your Microsoft Word:

whether you‘re the CEO or secretary you‘re all seeing the same icons and options. They‘re

basically like tools. And it‘s all jyaada lafda nahee when you‘re thinking of capturing

simulations, assessing design complexity/effort for a proposal and so on.

8. Wireframe Imagine you‘re ordering a cake for someone‘s 50th anniversary. It‘s a big deal. You‘re spending

a lot of money and you want a say in exactly how the cake will be. ―The cake will be a series of

layered circular cakes‖. That enough detail? No? ―The cake will have decoration on each

circular level.‖ That tell you enough? No? Okay how about this sketch:

ALSO ON THE MENU, A LEANING TOWER OF PIZZA.

And that‘s a wireframe. It‘s still a far cry from the final thing‘s appearance: it doesn‘t get into

questions of branding, color schemes and so forth. It just says ‗these are the identified key

things that should be there for the user, and this is roughly where they will be‘.

So the difference:

TA-DA!

The non-flour version of a wireframe would be something like this:

(Source)

9. Functional Specifications, Use Cases, Test Cases, Software

Requirements Specifications and More Forget those terms, what do these spoons have in common?

Very good, they‘re all wooden, they‘re all… spoony kitchen utensils.

Now what differences do these spoons have?

Some can shovel, some can scrape, some can scoop, and so on.

The documentation is like that. They all essentially describe what the software will do, how

and why. It‘s just each one does that in varying degrees.

Functional specs describe the nuts and bolts design and specs for an application.

Use cases describe what is required of the application in terms of behavior in various scenarios,

across workflows, and so on. Use cases help application designers understand what should

happen.

Test cases describe how the application should behave in various situations so that testers can

verify if it‘s actin‘ funny or everything‘s fine. So test cases are based on use cases, and they

factor in validation requirements, testing requirements and stuff so that testers can ensure

that the behavior detailed in the use cases is actually supported.

Software requirement specs are all of the requirements of a piece of software – not just

technical, but even aesthetic, contractual and blah.

There. So now you know some funky terms in software. Wasn‘t that hard, was it!