The Fallacies of Design

The Fallacies of Design
While reading the various UML/Pattern/Architecture/OO/XP/TDD books and literature, I think most authors forget some of the basic maladies that plague software projects. Or perhaps because there are no solutions for the problems, it is best to ignore them. So far there have been very few insurmountable problems as regards to the technologies involved in projects that I have worked on. They have always been workarounds , tactical pathworks and other hacks. But there are the other issues which can derail a project.
So here are the various fallacies I have seen

1. There is a best solution that solves your problems.


2. Systems that you need to integrate/interact with can be changed to implement the best possible solution


3. People within the project will cooperate with you. People outside the project will cooperate with you


4. The People defining the requirements know what they want. Once a requirement is signed of by said rule, it wont change


5. Budget is infinite, Time is infinite


6. Managers can manage, Designers can design, Analysts can analyze and coders can code.


7. The solution to any problem is a pattern/platform/approach/methodology


8. If the test cases pass and code coverage is > x% then there wont be problems in the wild


9. People will always tell the truth


10. Murphys law does not apply to software.

None of these fallacies are technical. They aren’t meant to be. Its rarely the technology that derails a project.

Design Patterns v/s Experience

While reading through TestNG and comparing it with JUnit, it is obvious that TestNG is far simpler to use and at first glance looks to be designed better (or has more features). Note I haven’t written a single TestNG test yet.
And I remembered reading , when people complained about the limitations of JUnit that JUnit was designed as a framework that could be extended. And how JUnit had used all sorts of design patterns.
Which leads us to Design Patterns v/s Experience question. I do not suggest these two are mutually exclusive. The comparison of JUnit and TestNG is not strictly fair, and neither is this a feature by feature comparison, nor an indictment of design pattern approaches. Its simply that having JUnit (and its varied extensions around) allowed Cedric to create a better framework. Like not having to implement a class or interface for your tests. The different ways of running setup (as opposed to the design pattern used by Gamma and co.) . And while a catalog of Design Patterns exist, how do you quantify or catalog the Experience that allows you to select the correct Design Pattern?
Experience also teaches you when design patterns need not be used. (oh yes there are cases, but I leave that for a separate entry).
And if you had to choose a candidate with Design patterns on his CV(All candidates know factory,singleton,value object, dao and session façade) or one who seemed to have the experience, choose the guy with experience (This has nothing to do with 6 yrs experience and no DP in CV!)

Youth And Responsibility

Its obvious to anyone who thinks about such things that the only hope for the future are the youth. The big picture aside, lets look at youth only in the context of the workplace. Its also painfully evident that no one trusts the young trainees just out of the trainee program.
We are of course polite. They dont have enough experience we say, we cant risk it - what if they screw up on production?. We(the experienced people, the guys who have seen it all) can't spend all our time reviewing what the trainees are delivering. In other words it is easy to find rational arguments which prevent us from delegating responsibility/tasks to the young 'uns.
The plain truth is that we don't trust them. Or we trust that they will screw up.
Which is a sorry state of affairs.
I need to break out of this mental block . And I think I'm still someone who trusts the younger people around him a lot more than others.
But it has to improve

The Anarchist Management Model

One of the things that keeps occupying my thoughts these days is how much that we learn from life can be applied to our work.
One of the major problems in work can be summarised as Management. Most non managers would not hesitate in calling Management evil , and only perhaps were we really feeling charitable would we call Management a necessary evil. But Managment persists as a practice , even worse you have younger generations(am i really this old?) growing up wanting to be managers. You have people joining the project stating that they want a management role.
As such I'm against all sorts of management in principle. I think this has to do with the fact that as a form of governance I prefer Anarchy. And currently Management is a pseudo democratic dictatorship. You dont really have a say on who is your manager (hence a sort of dictatorship) but perhaps results /feedback can get the manager removed.
Id like to see a project where people take responsibility for their actions. Divide the work amongst themselves based on their competencies. Set targets for themselves and meet them. Resolve their problems without needing outside intervention.
Could it Happen ?

Culture and Design

Does the culture we have been brought up with affect the design work we do?
Case In point.
One of the clients of my company is spending large amounts of money to attain homogenity in the technology/platforms/systems it uses to avoid the integration problems that arise with heterogenous systems.
My personal preference has always been to develop systems independently using whatever is best for that system. And then figure out ways to integrate them.
Both approaches have their shortcomings and advantages of course.

Im wondering if the fact that diversity that is so much a part of Indian life has anything to do with my preference. If so i'm grateful for it.

Interviews

One of the things that is part of my my workstack is obliging Recruitment whenever they want some J2EE interviews conducted.
It is a highly painful experience.
On one side we have the questions that we are given to ask by Theoreticians who seem to be detached from real world programming (what is the output of i++ + ++i or how many overloaded constructors does the File object have - note these arent really questions we are supposed to ask , but you get the idea) .
On the other side we have the candidates. It looks like they come prepared to answer questions like the above. And because I always begin with what are the technical details of your project and what did you work on, 9 times out of 10 the candidate looks back with a blank stare. Or provides some inane details like There is a login screen , the user enters his password and is taken to his homepage. The End. I am not alone in this regard. Other people from my company have expressed similar sentiments. Perhaps the reason is no good candidates are applying to my company :-) .
This actually leaves only one way out if we want competent resources. Hire people out of college. Train them and then mentor them.
It remains to be seen how successful this will be

Loyalty

Do you remember the time you were in school? The time when your school was the bestest there was , when all the people in your school were smarter than any other school , where the grounds were better to play in than in anyone else's school, where the teachers were the best and kindest, where the principals were stern but what the heck you liked them anyway.
I do.
One of the things you learnt in school was loyalty and that loyalty begets loyalty. And there was a thing called Honour.Do you remember the time the teacher asked who did whatever and everyone knew but no one said a word.? Atleast my school(and with that i include the campus , the teachers and my fellow students) did try to teach me that. But then i did tell you it was the best school.
One of the first things that struck me in the induction speech when i joined by company (5.5 years back) was the thing someone from senior management said. He said You should not be loyal to the company. He said the company does not even want your loyalty. It will do what is best for itself and you should do what is best for yourself. He went on to refer to the practice in my company of giving long service awards at the end of 3 years and joked about it.
The Achieving excellence session went on to teach you new keywords WIIFM WIIFU (whats in it for me , whats in it for us)
At that time i would rather listen to If(Rudyard Kipling)
If you can talk with crowds and keep your virtue,
Or walk with kings - nor lose the common touch;
I resolved that this was a case of keeping my virtue while walking with the crowd and thefact that the company doesnt care for my loyalty does not in any way prevent me from being loyal.
I suspect that i should have bowed to experience instead of indulging in youthful idealism.
So much so that the fact that i have stuck with my company for 5 and a half years is now a liability. Supposedly IT HR people feel that if a software engineer sticks in the same company for more than two years there is something wrong with him - lack of ambition, initiative whatever.
So why am i still in my company