September 30, 2009 at 4:55 pm
· Filed under Engineering, Thoughts, mindset, programming ·Tagged approach, conflict, creativity, Engineering, experience, ideoloy, innovation, irrational, linkedin, mindset, nonintellectual, patterns, software, tradition
If you notice, you may observe that most of our nonintellectual discussions and conflicts 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 patterns — not 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, at least in our local industry as I see.
1. The Fundamentalist Craftsmen or Blind Followers
There are people who have strong belief in old 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 failure is 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 the on-site front-office team to let them update the documents. In absence of their access on offline documents the local team shares the documents via email with the remote 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 shareing the documents on email. The term coined here is Brute Force approach as Steve McConnell called it
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 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 legacies: 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 in 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. The term coined here is “Silver Bullet” as Steve McConnell says.
3. Engineering Mindset: the most needful
The moderate mindset – or engineering mindset as I say– tends to utilize and exploit the experience, invested by the lots of great minds avoiding useless reinventions but never shy to address the issues with in the particular scenario, if it doesn’t fit with. The mindset says that understand your objective whether it’s 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 it’s a going concern but it’s not the ultimate goal of an engineer instead it’s to deliver the most optimal and economical.
A single practice may have different 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, dont’ 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 believe that I am right all the way; considering that I’ve limited amount of skills, knowledge, experience. You comments and disagreements wil be anticipated hoping they’ll help us having a balanced mindset.
Permalink
April 15, 2009 at 10:04 am
· Filed under .Net, Engineering, programming, software ·Tagged .Net, C#, coding, date, datetime, java, practices, programming, string, time, typed
One of the most common mistakes programmers do is to treat the DateTime as string, or in another words always assuming a specific date format.
How DateTime Works
In strong typed languages like Java and .Net, DateTime contains the
date and time value as a consolidated numeric value without any format specification.
The culture aware ToString() method of DateTime converts the time value
according to the culture/format specifications of the system and configuration.
How to use?
Always use DateTime type for date and time values especially when savin/retriving DateTime values from/to Database.
Always use command parameters with proper types for passing values from application to database.
What to avoid?
Using string to contain DateTime values can become a disaster especially in large application.
You may find yourself trapped in a Format-Hell if you are assuming any particular format in calculation or representation
Never pass Datetime values as string across platforms or contexts for instance application-to-database
Permalink
August 29, 2008 at 3:57 pm
· Filed under Management, workplace ·Tagged environment, linkedin, Management, office, parasite, parasitism, social, teamwork, workplace
Parasitic workplaces are kind of Catch-22, at least for the hosts of parasites. Here host–according to the biological definition–is one who harmed by a prolonged, close association with the parasite, who is benefitted. As per Wiktionary, a parasite is “A useless person who always relies on other people’s work and gives nothing back”. Host, one who actually works for her employer, adding value but shares the credit with the parasite and unfortunately sometimes handovers the lion’s share.
Here I refer it a Catch-22 because at these workplaces, usually the hosts cannot get rid of the parasites unless they withdraws from their jobs. Increment in hosts’ efforts also strengthen their parasites. Their efforts are viewed as average performance of the team; a team comprise of hosts and parasites. Even sometimes the parasites get more than their hosts as the hosts struggle to increase the productivity while the parasites struggle to get the credit.
Usually in starting few months the host tries to perform more in hope of getting appreciation but it doesn’t help, instead it increases the average productivity and she finds her parasite being appreciated for it.
Having good ethical behavior, it doesn’t instantly bother hosts to share their credit with others. But when it becomes the norm, it sucks. The host which are the actual producers, start demotivating. Then they become divided in two different groups: the optimists and the pessimists.
The Optimists
Only few of them become optimist who still believe in performance, they try to bypass the glass ceilings to show the actual picture to senior management, who are too busy in their out-of-the-box matters. Again most of them fail to adapt such kind of behaviour that is, to put efforts to present what you have done instead of doing more, which doesn’t comply with their job description. Again Catch-22, they cannot rid of their sense of duty.
The Pessimists
Pessimists realize that they have been caught by Catch-22. This realization and the awareness that the lack in their performance will also weaken their parasites kill their enthusiasm, ruin their motivation and decrease their productivity. This situation helps in very rare cases when this decline in team performance could disturb the management and convince them to look into the matter.
This post is pending, author is still working on this post …
Permalink
June 16, 2008 at 12:16 pm
· Filed under programming, software ·Tagged agile, agility, chicken, Control, development, life cycle, linkedin, misconception, model, pig, responsibility, scrum, SDLC, software
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
Permalink
June 2, 2008 at 3:21 pm
· Filed under .Net, programming, software ·Tagged ASP.Net, AutoEventWireup, event, hits, load, Loading, Page, page_load, twice, why
If you are observing load event twice in a post back in ASP.Net page, check the following:
- If Page_Load handler defined in Codebehind then AutoEventWireup property should be “false”
- Check if you have mistakenly multiple event handlers registered for an event
- Src or ImageURL attribute of your image control are defined and not empty (you can put %20 for blank)
- bgColor or background is empty
Last two problems usually appears in one browser while disappears in other.
Permalink
May 26, 2008 at 12:20 pm
· Filed under Management ·Tagged dedication, human resource, Management, parasitism, people, performance, sincerity, workplace. motivation
I don’ t know whether it’s a common phenomena 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 people 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.
Permalink
May 26, 2008 at 11:38 am
· Filed under Uncategorized ·Tagged managerial, market, software, technical, trend
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.
Permalink
May 15, 2008 at 8:15 pm
· Filed under Engineering, software ·Tagged axiom, complexity, Control, development, Engineering, gall, jhon, law, murphy, optimism, pessimism, simplicity, system, systementics
- The Primal Scenario or Basic Datum of Experience: Systems in general work poorly or not at all. (Complicated systems seldom exceed five percent efficiency.)
- The Fundamental Theorem: New systems generate new problems.
- The Law of Conservation of Anergy{sic}: The total amount of anergy in the universe is constant. (“Anergy” := ‘human energy’)
- Laws of Growth: Systems tend to grow, and as they grow, they encroach.
- The Generalized Uncertainty Principle: Systems display antics. (Complicated systems produce unexpected outcomes. The total behavior of large systems cannot be predicted.)
- 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.
- Functionary’s Falsity: People in systems do not do what the system says they are doing.
- The Operational Fallacy: The system itself does not do what it says it is doing.
- 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.
- Systems attract systems-people. (For every human system, there is a type of person adapted to thrive on it or in it.)
- The bigger the system, the narrower and more specialized the interface with individuals.
- A complex system cannot be “made” to work. It either works or it doesn’t.
- A simple system, designed from scratch, sometimes works.
- Some complex systems actually work.
- A complex system that works is invariably found to have evolved from a simple system that works.
- 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.
- 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.
- 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.
- Systems develop goals of their own the instant they come into being.
- Intrasystem{sic} goals come first.
- The Fundamental Failure-Mode Theorem (F.F.T.): Complex systems usually operate in failure mode.
- A complex system can fail in an infinite number of ways. (If anything can go wrong, it will.) (see Murphy’s law)
- The mode of failure of a complex system cannot ordinarily be predicted from its structure.
- The crucial variables are discovered by accident.
- The larger the system, the greater the probability of unexpected failure.
- “Success” or “Function” in any system may be failure in the larger or smaller systems to which the system is connected.
- The Fail-Safe Theorem: When a Fail-Safe system fails, it fails by failing to fail safe.
- Complex systems tend to produce complex response (not solutions) to problems.
- Great advances are not produced by systems designed to produce great advances.
- The Vector Theory of Systems: Systems run better when designed to run downhill.
- Loose systems last longer and work better. (Efficient systems are dangerous to themselves and to others.)
- As systems grow in size, they tend to lose basic functions.
- The larger the system, the less the variety in the product.
- Control of a system is exercised by the element with the greatest variety of behavioral responses.
- Colossal systems foster colossal errors.
- Choose your systems with care.
Permalink
April 10, 2008 at 5:11 pm
· Filed under Uncategorized ·Tagged development, methodologies, patterns, practices, software, support
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.
Permalink
April 10, 2008 at 5:08 pm
· Filed under programming ·Tagged .Net, application, asp, ASP.Net, cache, comperison, cookies, how, optimization, performance, session, sessionstate, state, versus, viewstate, web application, web development
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
Permalink
Older Posts »
