Ahmed’s Dev-Shop

Take the lead

Posted in Uncategorized by Ahmed Siddiqui on February 14, 2010

At the end of two years in revolutionary efforts like team building, strategy aligning, building a technical architecture and an efficient and simple programming platform we could come out of the state of deficiency and chaos, which is a norm of industry like ours (immature and subject to change) and people like us (developed by 3rd world’s education system). Fortunately, I had couple of people who were honest with their profession and people. They were just seeking for couple of cheap but rare organizational attributes like direction and appreciation.

Unfortunately, the senior and seasoned people in organizations usually do not realize that a fresh employee is just like a newly born baby. You can shape her according to your needs but you have to treat. These freshies do spare enthusiasm and passion but they lack direction and orientation. The assumption that they’ll start performing like their peers from the very first day, is nothing but a fool’s fantasy. Your team or organizations is like a moving bus whatever the speed is but these new passengers have to set their speed and you have to set their direction before they can jump into the moving bus.

Advertisements

Tradition vs. Innovation: story of an ancient war

Posted in Engineering, mindset, programming, Thoughts by Ahmed Siddiqui on September 30, 2009

If you ever noticed that most of our nonintellectual discussions and debates are wars between tradition and innovation. Here you may find a person trying to convince others that one should stick with the legacies: experienced, practices, and patternsnot necessarily using the said words but some contextual jargon— while the other person is contradicting like if  only innovation and creativity can make a difference or in other words you learn as you go. The same quarrel exist in our software engineering field.

1. The Fundamentalist Craftsmen or Blind Followers

There are people who have beleive only in proven practices. They always have the same number of documents, same life-cycle, identical design, and unbelievably a single strategy for every project. The most surprising point for me is that even the consecutive failures are unable to make them believe that there’s something wrong. Instead of trying to make some improvements and searching for the shortcoming in their practices and strategy, they start believing that failure is a norm, or it’s not failure at all. For instance, you’ll hear them saying “Clients never get satisfied” or “Losing deadlines is a norm in our industry”.

Example —makes things easier

In a software project, the offshore back-office development team shares the documents reside in their local repository with the on-site front-office team to let them update the documents. In absence of their access on offline document repository, the back-office team shares the documents via email with the front-office team. Obviously they get frequent version conflicts in documents and when it happens, they arrange a meeting and manually resolve the conflicts in the documents.  For months, they suffer with this problem but avoid change in their practice e.g. having an online document repository instead of sharing the documents on email. This approach is named as Brute Force approach by Steve McConnell.

2. The Innovator –or scientist, we can say

Away from the above category, the innovators are what most of our new graduates comprise of. They start with buzzwords like Web 2.0, cloud computing and believe that legacy practices are all obsolete and that the senior folks are not creative at all. They drive their projects for learning, ignoring the ground realities they neglect the cost and risk of change and avoid exploiting legacy patterns and practices. Since they believe that they make things better than they are, it’s possible if you see them writing their own DB connection pooling for technologies having built-in connection pooling or writing their own classes from scratch instead of extending the existing one. They often try to make simple things state-of-the-art and having insufficient knowledge and experience they get lost in the middle. This approach is named as “Silver Bullet approach” by Steve McConnell.

3. Engineering Mindset: the most needful

The moderate mindset — or engineering mindset as I say— tends to utilize and exploit the experience, invested by lots of great minds avoiding useless reinventions but never shy addressing the issues with a practice in the particular scenario. The mindset says that understand your objective whether it should be build-to-learn or learn-to-build. It says that to be honest and successful, an engineer shouldn’t behave like a scientist who build and destroy just for learning. And it says that there’s always room for improvement since improvement is a continues process and a going concern but it’s not the ultimate goal of an engineer which is to deliver the most optimal and economical.

A single practice may have various out comes when followed with or without reason. So, if a practice is being followed by majority, most probably there are reasons, try to find them, don’t shy asking other followers if you couldn’t,  but if nobody else knows, you have at least one reason to avoid it. Better to have your own with reasons instead of following blindly.

a request

Being an engineer, I do not think, I am right all the way; considering that I’ve limited amount of skills, knowledge, and experience. Your comments and disagreements are highly anticipated hoping it’ll help us having a more balanced mindset.

Pigs & Chicks

Posted in programming, software by Ahmed Siddiqui on June 16, 2008

I couldn’t stop myself laughing out loudly when first time I came across the following paragraphs about some Roles defined in Scrum —an Agile development modal.

 

Several roles are defined in Scrum; these are divided into two groups; Pigs and Chickens, based on a joke about a pig and a chicken.

A pig and a chicken are walking down a road. The chicken looks at the pig and says, “Hey, why don’t we open a restaurant?” The pig looks back at the chicken and says, “Good idea, what do you want to call it?” The chicken thinks about it and says, “Why don’t we call it ‘Ham and Eggs’?” “I don’t think so,” says the pig, “I’d be committed but you’d only be involved.

So the pigs are committed to building software regularly and frequently, while everyone else are chickens that are interested in the project but are really irrelevant because if it fails they’re not a pig, that is they weren’t the ones that committed to doing it …

 

The misfortune is that sometimes projects are implemented with the above incomplete and unbalanced specification. Following is the remaining part of this paragraph:

… The needs, desires, ideas and influences of the chicken roles are taken into account, but not in any way letting it affect or distort or get in the way of the actual Scrum project.

 

Responsibility and Influencing Power should meet at an equilibrium point just like Demand and Supply in economics. Otherwise if you are changing x, you are implicitly changing y. And if you think you can control it, just give it a try.

http://en.wikipedia.org/wiki/Scrum_(development)#Scrum_roles

Trends in Software Job Market

Posted in Uncategorized by Ahmed Siddiqui on May 26, 2008

Following trends have been concluded by me after conducting interviews and discussing with my juniors, peers, seniors, and some students.

  • Most of the small software houses have the following hierarchy:

CTO/Dept. Head >> PM >>TL >> SSE >> SE

  • Most of the Resource Managers (Team Leads) are planning to become Project Manager
  • Senior technical positions–Architect, for instance–are not available for seasoned technical people
  • Senior Software Developers are planning to become Team Leads to get raise in benefits instead of focusing on scarce senior technical positions
  • Most of the resources have working experience of small-size offshore projects, they don’t have the experience and expertise of Enterprise Solutions
  • Most of the fresh graduates prefer better salary on career growth & learning
  • After initial 2 years, having some quick job-switches, some of them realize that if they could learn, they could earn more. Then they change their mind to prefer learning over adhoc monitory benefits
  • It’s becoming general perception among software industry that to become a project manager is the shortest path to get fat salaries
  • Computer Science Graduates are preferring to get admission in MBA instead of MS
  • In MS(Computer Science), Project Management is becoming a buzzword
  • It seems that in few years, we will have greater number of Managers and lesser number of technical resources, at least in software development

Disclaimer: This are my personal observations, not unnecessarily true.

How to get the worst of all worlds

Posted in Uncategorized by Ahmed Siddiqui on April 10, 2008

 
This is the story of ancient war between Software Scientist and Software Craftsmen on the ground of Software Engineering
The Scientists

Slogans:
   Let’s reinvent the wheel
   Complexity is charm

   Think out-of-the-box (never look inside)

Whenever company gets a project the developers are in search of well-hyped patterns and practices. Whatever the projects require, whatever the timelines are, they follow impressions, seeking complexities to passionate their lives. The problem is they want to combine the universal truths they get from their gurus, with the hypes. They get the compliance in few of the cases. It becomes a routine that start with complexity and when you stuck, let the things fly.
They often suggest the solutions they think they should learn. According to their point of view: software projects are to create a difference, even if the project fails, even if they do not add any value, if they implement state-of-the-art technologies, they consider it success.

The Craftsmen: the delivery people
Slogans:
We deliver
Quality is just a fantasy, don’t talk about it
Ad-hocism
Research is a synonym of time-wasting;


Fortunately some of the projects who comply with hyped patterns and rigid practices succeeded to achieve the timelines, thanks fortune. And now the support people are ready to show their quick solutions. They’ll show that the tasks completed by the developers in month was just a matter of days. Thanks to encapsulation; no one knows what’s inside J

Till the day the application is safe from the quick solutions of support staff, it shows some stability. And once it gets the first JUGAR—synonym for a careless ad-hoc solution in Urdu language—the application becomes more addicted to their JUGARs and provides more options for support people to prove their problem solving skills.

Why Patterns Suck?

Posted in Engineering, mindset, programming, software, Thoughts, workplace by Ahmed Siddiqui on April 10, 2008

Surprised when I heard some people saying “Patterns suck”, I was eager to know why they hate these precious guidelines which often save us from reinventing the wheel, letting us using it.

Fortunately after just few days I had to work with some confident developers, known as pattern-lovers. Having plenty of technical knowledge, they were used to count the names of patterns–and there authors–on finger tips. People, you can speak technobabble with, for not just hours but for days. I admired them and found myself among blessed people.

Later I found something strange, besides all their knowledge they had very few success stories and their management was not satisfied with their problem solving skills.

I had started observing the causes of their failure. Mean while I had to design an architecture for a coming enterprise business application. I started scaffolding by enhancing and optimizing my legacy libraries and framework with my team. I asked the experts to review my approach to let my approach become foolproof.

Geeks love technical discussions so I got a prompt response and they started highlighting the weaknesses, I was very glad as I got a chance to improve. But unexpectedly most of the issues identified were as follows:

Geeks: Aren’t you using NHibernate (a port for Hibernate for .Net)?

Me: Nope, I personally admire NHibernate for its OO approach and database independence but I think that this application does not have complex business processing, instead it mostly comprise of chatting between the user and database. It also comprises of complex reports which is not a specialty of NHibernate. While our tailored framework provides Report Factory and configuration as well as tiered approach for reporting. Another reason is that our expertise on NHibernate do not allow us to use it in a time-critical project at this stage.

Geek: What? Do you know where NHibernate came from, it’s a port of Hibernate, being used in the most powerful language “Java”. It has nothing to compete with MS’ ADO objects.

Me: Yes, I do agree that Java and it’s platforms are lot more maturer but since every language or technology has some of its own strengths and weaknesses, our framework and libraries are optimized with the strengths of .Net. Our wrapper classes exploiting some new features provide in the latest version of .Net.

Geek: Hey don’t use ADO.Net objects, they do nothing but violates layering These objects are mess. You should use pure objects that’s why I recommended you to use NHibernate.

Me: I think it depends that how are you using them, in our scenario they are completely database independent because they are boxed in generic objects and are created by abstract factories so we can enjoy Inversion of Control, Polymorphisms, and Database Independence.

Geeks: These libraries are not open source, you don’t know what they have written in it.

Me: I admire the benefits of open source but these object are rich, free, built-in, tested and performing well in enterprise applications. I do not very often use them but I found them very useful in such kind of applications.

Geeks: You incorrectly applied this pattern; let me show you the documentation.

Me: This pattern like other patterns have different applications, I am following this approach because it fits well in this scenario. This flexibility is also allowed by experts.

Geek: No, patterns should be followed as is. They are not to be compromised for performance or whatever. And remember enterprise applications, built on great technologies like EJB, looks graceful even if they are not enough performant.

Geek: Increase your number of layers like we have did in that application. You have not decoupled enough.

Me: Yes previously I did have the same number of layers but I found it as an overkill in this project, so I modified this version for medium-sized performance-hungry applications.

Geek: And why did you coupled these two major tiers, this is an unacceptable violation of N-Tier Architecture

Me: No, these are still two different layers, but I am keeping them in a single project during development as most of the developers are working on both layers. They still can be deployed on different servers.

Geek: I’m still not satisfied, a lot patterns have not been used, recommended by the gurus and we follow them because we know they are the best.

Me: They might have recommended it for some different type of project and this approach may be suitable in that particular scenario.

Geek: We found their practices the best in all type and size of projects, whatever, it’s not that simple you think it is, you have to add a lot more complexity.

Me: May be you are right as I found you very knowledgeable but I learned and believe that a complex system that works is invariably found to have evolved from a simple system that works.

… that’s how I got to know somehow why people hate patterns”