Ahmed’s Dev-Shop

Don’t let them leave, don’t get them changed

Posted in Management by Ahmed Siddiqui on May 26, 2008

I don’ t know whether it’s a common phenomenon or not and whether it has been written in HR books or not. Having being hunted by this problem during my early days, when I got the first chance to lead people, I started observing them silently, without showing any reaction, letting them be more and more exposed.

I collected events and behaviors, analyzed and discussed these behaviors, concluded the results, and to make the decision making process complete and fool proof, I started getting feedback. The results were positive.

So being a line manager, are you able to identify some precious resources under your supervision who seem to be ordinary?

Common characteristics of these resources

  • These people are often too shy to communicate
  • They often seek opportunity to add any value to their company, even if they are not satisfied
  • They do not show unusual efficiency in the presence of their seniors because of their honesty
  • Often they seek for a chance to help their colleagues without expecting any return
  • You may find them helping others even if they have their own tough time lines
  • If they respect you, they would not tell you, instead they’ll work for you harder
  • They’ll contradict you , in your own interest
  • Sometimes they fail to meet the time lines because they do not want to compromise on hidden quality, while others do
  • They utilize their leisure time in solving some other problems your company may face
  • Sometime they silently solve some potential problems which can become a disaster for you in future


How to deal with them

If their responsibilities are some back office or technical tasks, their weaknesses may be in your favor along with their strengths

– Most probably they would not ask you for appreciation and incentive. You have to identify their micro achievements which may have resolved some macro problems; appreciate them

Don’t let them get rid of innocence and honesty, appreciate these characteristics

Be aware of some smart asses under you who can exploit these innocents by taking their credit

When they lose they time lines because they were helping others, don’t criticize them for it. Just appreciate them and tell them:

  • To prioritize the criticality
  • To prioritize their own task, if criticality is same
  • Or to discuss it with you (supervisor)

Being a line manager, you are not necessarily dealing with managed people. They may lack some skills while having some others. You have to study your resources thoroughly and closely. Identify their actual value instead of the perceived value. May be you would have a different perception after this practice.

Advertisements

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.

Laws of Systemantics by John Gall

Posted in Engineering, software by Ahmed Siddiqui on May 15, 2008
  1. The Primal Scenario or Basic Datum of Experience: Systems in general work poorly or not at all. (Complicated systems seldom exceed five percent efficiency.)
  2. The Fundamental Theorem: New systems generate new problems.
  3. The Law of Conservation of Anergy{sic}: The total amount of anergy in the universe is constant. (“Anergy” := ‘human energy’)
  4. Laws of Growth: Systems tend to grow, and as they grow, they encroach.
  5. The Generalized Uncertainty Principle: Systems display antics. (Complicated systems produce unexpected outcomes. The total behavior of large systems cannot be predicted.)
  6. Le Chatelier’s Principle: Complex systems tend to oppose their own proper function. As systems grow in complexity, they tend to oppose their stated function.
  7. Functionary’s Falsity: People in systems do not do what the system says they are doing.
  8. The Operational Fallacy: The system itself does not do what it says it is doing.
  9. The Fundamental Law of Administrative Workings (F.L.A.W): Things are what they are reported to be. The real world is what it is reported to be.
  10. Systems attract systems-people. (For every human system, there is a type of person adapted to thrive on it or in it.)
  11. The bigger the system, the narrower and more specialized the interface with individuals.
  12. A complex system cannot be “made” to work. It either works or it doesn’t.
  13. A simple system, designed from scratch, sometimes works.
  14. Some complex systems actually work.
  15. A complex system that works is invariably found to have evolved from a simple system that works.
  16. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over, beginning with a working simple system.
  17. The Functional Indeterminacy Theorem (F.I.T.): In complex systems, malfunction and even total non-function may not be detectable for long periods, if ever.
  18. The Newtonian Law of Systems Inertia: A system that performs a certain way will continue to operate in that way regardless of the need or of changed conditions.
  19. Systems develop goals of their own the instant they come into being.
  20. Intrasystem{sic} goals come first.
  21. The Fundamental Failure-Mode Theorem (F.F.T.): Complex systems usually operate in failure mode.
  22. A complex system can fail in an infinite number of ways. (If anything can go wrong, it will.) (see Murphy’s law)
  23. The mode of failure of a complex system cannot ordinarily be predicted from its structure.
  24. The crucial variables are discovered by accident.
  25. The larger the system, the greater the probability of unexpected failure.
  26. “Success” or “Function” in any system may be failure in the larger or smaller systems to which the system is connected.
  27. The Fail-Safe Theorem: When a Fail-Safe system fails, it fails by failing to fail safe.
  28. Complex systems tend to produce complex response (not solutions) to problems.
  29. Great advances are not produced by systems designed to produce great advances.
  30. The Vector Theory of Systems: Systems run better when designed to run downhill.
  31. Loose systems last longer and work better. (Efficient systems are dangerous to themselves and to others.)
  32. As systems grow in size, they tend to lose basic functions.
  33. The larger the system, the less the variety in the product.
  34. Control of a system is exercised by the element with the greatest variety of behavioral responses.
  35. Colossal systems foster colossal errors.
  36. Choose your systems with care.

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.

How to choose from Viewstate, SessionState, Cookies and Cache

Posted in programming by Ahmed Siddiqui on April 10, 2008

Problem with Web Applications

Web applications are stateless, means once a web page is rendered from server to client, nothing in the page remains on server and the next time user submits the page, the page will be called and created from scratch.

ASP.NET provides following solutions to solve this problem:

1- Viewstate
2- Session Variables
3- Application Variables
4- Cache
5- Cookies

Now the question arises that when to use what?

1- Viewstate

Viewstate is a hidden fields in an ASP.NET page, contains state of those controls on a page whose “EnableViewstate” property is “true”.
You can also explicitly add values in it, on an ASP.NET page like:
Viewstate.Add( “TotalStudents”, “87” );
Viewstate should be used when you want to save a value between different round-trips of a single page as viewstate of a page is not accessible by another page.
Because Viewstate render with the page, it consumes bandwidth, so be careful to use it in applications to be run on low bandwidth.

2- Session Variable

Session variables are usually the most commonly used.
When a user visits a site, it’s sessions starts and when the user become idle or leave the site, the session ends.
Session variables should be used to save and retrieve user specific information required on multiple pages.
Session variables consumes server memory, so if your may have a huge amount visitors, use session very carefully and instead of put large values in it try to put IDs and references

3- Application variables

Application variables are shared variables among all users of a web application
Application variables behave like static variables and they are substitute of static variables as static variables are stateless in web applications
Only shared values should be persisted in Application variables, and as soon as they are not in use they should be removed explicitly.

4- Cache

Cache is probably the least used state feature of ASP.NET.
Cache is basically a resource specific state persistence feature, means unlike session it stick with resource instead of user, for instance: pages, controls etc.
Cache should be used or frequently used pages, controls, and data structures
Data cache can be used to cache frequently used list of values e.g. list of products

6- Cookies

Cookies are some values saved in browsers for a particular website o publicly accessible
The purpose of cookies is to help websites to identify visitors and retrieve their saved preferences
Cookies are also used to facilitate auto login by persisting user id in a cookie save in user’s browser
Because cookies have been saved at client side, they do not create performance issues but may create security issues as they can be hacked from browser

Finally remember the following points on your finger-tips:

1- Viewstate is bandwidth hungry
2- Session variables are memory hungry as per number of users
3- Applications variables are shared
4- Cache is memory hungry as per number of resources
5- Cookies are the least secure

http://www.codeproject.com/KB/aspnet/HowToChoose.aspx

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”