Contextor 0.2 released

After a couple of months of redesign and coding, I released Contextor 0.2. It is still somehow beta but it works rather nice.

Software Experience - Trust

Trivially simple and obvious yet effective and fundamental. The primary goal in every software development process is to deliver a specified application in an acceptable qualitative operational state. Apart from all the technical issues, activities and concerns in every software project, there are many others usually referred to umbrella activities. The umbrella ones usually include project management and environmental activities both to lead and support the development process in all phases. Talking of project management, here emerges the simple practice of trust. I have experienced different aspects of trust recently as in:

The customer does not know exactly what he wants. They hold some informal meetings with the contractor to reach a conclusion yet not so promising. The contractor initiates some development moves letting the customer know of. Customer adaptively accepts some general impressions and issues an OK to start the work. This also may happen when the customer has some legacy system and desires to create and build a new one with more exciting features; still, the customer is unsure of what he wants. Alongside this mutual trust, comes the flexibility of the contractor. Usually, the contractor is abound to being firm and fixed on the rules and scope exactly mentioned in the contract not to lose time or extra costs on something that will not be paid for. When trust gets some more credit in communications between the customer and the contractor, the flexibility of the contractor also rises; it seems that trust can act as a catalyst to bond the tie between two sides. As a personal experience, trust makes me happier when I'm in either sides of this communication. The trust gives me the feeling that this work will sure end in a win-win situation. And, I admit that there are many projects in very very very larger scales that require some official bureaucracy before any start; still I firmly believe that still some form of trust should be established and grounded during any negotiations in initiative phases of any such project. More formally, considering the scalability and supplementary requirements of a software project, there can still be ways to inject the trust in different levels of communication between the customer and the contractor to boost the process and ultimate quality.

What about the money? On one side: no trust, no software. And, on the other: no trust, no money. Simply chemically, the mood seems to be conveyed to either side of the project. On one hand, when the contractor comes to the vision (even if false) that the customer is not willing and determined to pay off for the work done, he becomes more and more reluctant and carefree of the concerns in the project trying to just and just abide to the scope of the contract and not a single bit more. The same atmosphere gets provoked on the customer side observing that the contractor is not so willingly doing his job and duties according to the contract; leading to critical faultfinding mannerism. Though, when two sides have confident trust in one another, the financial matters on one side and software ones on the other tend to resolve more smoothly and automatically. There are situations in which, due to any reasons, the customer is not ready to do the finances; the contractor with the trust will sure continue the quality work as before with no hesitation. There are situations in which the contractor has financial needs or requirements in some period; why not and why not the customer shouldn't help him out if possible?! Sadly, this is not happening very often that could be a point of attention for managers in organizations and companies to cultivate the culture. The finance departments in many organizations usually play a crucial and ruling role that tends to be less flexible and adaptable; however, managers at the customer side should have authority to cope with situations in which their finances should be more flexible.

The Social Trust Culture. All the trust that we're talking about roots in the social and cultural foundations common and norm to a society. It is disappointing to admit that the trust in software project management will comply to the social common concept; if trust is not virtuous in the daily life in a society, it would be so hard and weary to create a base on which both sides could build their relationship upon mutual trust. In other words, we should have trust in daily communications, relationships, and interactions so that we can take this trust to some other level to the software project management and development process. If, for instance, lying is common in a society, it could be bitterly sadly factual that customers and contractors would not act upon trust in the other side. One other issue that should be considered is that if under any situation, cause, or justification, one side of the customer-contractor tie breaks the relationship trust or distrust the other side, the relationship is ill and, effectively annulled. When there is no pivot of trust in the software project management and process, each side will act upon his own priorities and concerns.

The views expressed in this post are all based on personal hands-on experiences in a couple of software projects all of which interestingly were and still are managed completely remote.

Related:

• Software Experience - Introduction

Software Experience - Introduction

To start with, I am Iranian (Persian). I left home to do stuff in Computer Science. I have couple of years of experience in software development and project management in a small company in Tehran; ASTA. Currently, I'm in the Netherlands, and out of many reasons I had to start some part-time co-operations in software sector here. During the period, there's been a lot of contrasts and comparisons to my previous impressions, I've interestingly come across that I'd like to share (thanks to Seyyed Jamal for his great idea to share these). Still, before that, I'd like to mention a few things:

• I am using English language rather than Persian (Farsi); I believe in true open source as in GPL; not the type that one says he supports and then ridiculously bans the resources to people around the world based on some witless rules and regulations. Also, using Persian may somehow lower the possibility of future collaborations. 
• I also admit that the main target audience will be Persian specialists in software, however, we'll be happy to share ideas with peers from around the world.
• The related posts are based on my personal background, experiences and viewpoints in software design, development, and project management; so, not necessarily based on scientific or proved theories in software.
• No comparison or differences mentioned in the related posts are meant at all to disrespect or disregard different people's attitudes, skills, or profession. They are only based on personal observations for discussions and analysis.
• Feedbacks in any language will be most welcome.

Related Posts:

• Software Experience - Trust