Breaking Winds Of Software Development

It is horrible. I am concerned about what are we going to do with software development from what I got to see during last week.

Look I will be frank. I am a mediocre programmer. Further programming doesn't stir anything inside me, once upon a time it used to do, but not now.

But even then one is immensely annoyed at the all around display of clueless behaviour which results in bad problem solving. Here follows broad instructions.

1. Problem Setting: Problems are intended to test skill of programmer to provide solution for real life scenario. Now it does make the sense to formulate the problem in a way so that robustness, flexibility, scalability, extensibility etc could be tested. However being general is different from being vague. Ultimately a problem is clear in its intent therefore it is possible to arrive at solution without assuming conditions which are grossly extraneous to the intended problem space. Vagueness give rise to unsatisfactory solutions which give bad feeling to the trainees. It also tells that the problem setter overestimates his intelligence and also is clueless in reality.

Be clear about your intentions while setting problem.

2. Problem Solving: We do know about plugin whore, but there is more of whoreness than we can possibly imagine, yes there is such a thing as being a pattern whore. The first step to solve problem, is to understand what the statement is all about. Which means to understand the requirements and constraints. To start pillaging the patterns without even having understanding based on a superficial reading is not the solving. Surely if members of gang of four were to encounter such a display of debauchery they would commit sepukku in horror.

Understand the problem statement.

3. Solution Discussion: Taking pleasure by inconveniencing others is human nature, but it is no excuse to be a moron. Specifically when you interrogate a solution for extensibility, flexibility or scalability, the extent of interrogation is limited by the domain which is specified implicitly or explicitly by the problem statement. For example if the problem statement is about devising a training scheduler for employees, don't analyze solution by attempting to applying it to other HR functions, it may or may not work, I mean what next ! Criticizing Jagadguru for not fitting monkeys with wings ?

Control your feelings.

# Bonus Wisdom

A. OOPS : Objected oriented programming (OOPs) is not about using the features that enable OOPs. It is about approach to problem solving. OOPs solves the problem by attempting to abstract the data and operations performed on data in terms of objects and their interactions with each other and the execution environment. This differs from procedural programming
which is about arriving at solution by strictly concentrating on steps through which solution could be arrived at.

Example: This is not OOPs

int x1,x2,y1,y2;

//Do initialization

int x3,y3;

x3 = x1 + x2;
y3 = y1 + y2;

Neither is this

int a[],b[];

//Do initialization

int c[];

c[1] = a[1] + b[1];
c[2] = a[2] + b[2];

Or even this !

class Int
{
public:
int i;
};

Int x1,x2,y1,y2;

//Do initialization

Int x3,y3;

x3.i = x1.i + x2.i;
y3.i = y1.i + y2.i;

This is OOPs

class point
{
public:
point add(point b);

protected:
int x;
int y;
};


point p1,p2;

//Do initialization

point p3 = p1.add(p2);

And for heaven's sake collection classes are not really OOPs !