During 2009, I was attending a Workshop about Strategic management and Leadership. It was at the recession time, I remember Professor
David Kirby telling us “Well, you have to adopt to market changes.. Always seek how you can create new opportunities from each problem”

It was like a golden advice that I won’t forget!

During the Egyptian revolution, we were in deep problems! No internet, No working office, general worries everywhere. Starting from Friday the 28th of January till Wednesday the 3rd of February No on in the country was working.. (except us , I think)..

We had a challenge, but we had a mission! We won’t leave our Clients without support. We took decisions that “whatever it will cost us, we won’t stop our support” . We used International Dial up, we challenged the curfew and we spent thousands of dollars on International calls and conferences.

When the internet came Wednesday the 3rd, we were energized enough to finish all our pending work in few hours. The response from our USA clients was really great, they were not only understanding but supporting and appreciating. We managed to turn it 180! From complete frustration to complete appreciation

Then, we looked at how we can help our country.. We started a new campaign (http://www.ana-masry.com). “I am Egyptian.. I will start by myself”.. The objective was to spread a video message having commitments about how each one can help creating a better Egypt.

My friend Mark Hillary took the imitative to spread our mission and good work even outside Egypt. He wrote a bunch of articles about us.. Enjoy reading them:

http://www.computerweekly.com/blogs/social-business/2011/03/i-am-egyptian-i-will-start-by-myself.html

http://itdecs.com/2011/03/how-egypt-carried-on-delivering-it-services/

We tried to say that what happened is not the original problem. The root problem is simply the growing congestion between people, and our Egyptian identity loss within these waves of negative thoughts spreading among us…

Hatred, depression, discrimination, congestion, fears… They all exist! They all tainted our True Egyptian nature that is full of peace and love. We believe that the Religion has a big role in Unifying and not separating people. Also, we believe that we are all responsible, we are all accountable, and we are part of the problem, consequently we are the key of the solution!

This campaign is purely developed by Ark Development staff. The Technology behind it is called “Personalized videos”, which applies user interaction approaches and makes the audiences part from a video Story. We had to do this within 5 days only to deliver our message effectively in time of need. We wish we had more time to contribute to a greater extent and make the video and its message much stronger, but time was so short.

We thank all our supporters (Tamer/Mohamed/Tony/Dina/walid/Yehyia/Marwa/…) and all others who gave us their photos to be a part from the video. I personally welcome all suggestions and comments. Please e-mail me your ideas/criticisms at (Amgad@arkdev.net). I will be happy to consider all of them in our next release or in a new personalized video Campaign.

We are proud to launch our first Web based Management application for companies in the Middle East Region “TAQAT”. TAQAT combines Strategic Management, Collaboration in Projects, Team communication, and Documents Sharing under a single platform.

TAQAT, which is an Arabic word that means “Energies”, expresses exactly the mission of our System. Companies where all employees have equal voice, share same knowledge base and feel complete fairness when being assessed will have their energies “unleashed“ for the benefit of the company.

TAQAT creates a wonderful working environment, by mixing new social networking features with management techniques. Employees will have in a single place their career path, training plans, tasks to do as well as social blogs and groups. TAQAT creates a highly effective working “community” that is productive, focused and fun.

TAQAT is developed by Samir Adel and his crew at Ark Development. The management model of TAQAT was initially developed by Mike Kramer, an Award-Winning Leadership Consultant living in Chicago, then tuned by Amgad Kaldas, Ark Development Owner and Manager to be more fitting with the companies in the Arab Region.

For me as one who was involved in Requirement Management process area for CMMI model in ArkDev and from my experience in requirement elicitation and requirement development, I found this good article about writing quality requirement for Karl E. Wiegers that represents our model, templates and tools – I like to share it with you.

Software Requirements Specifications (SRS) is the most important work product we can have in our project. All project stakeholders connect to SRS as a reference to everything in the project.

For the customer, SRS is the only thing he/she can read, understand and contribute in. For company, SRS is what customer signed off on which means this is what customer need and so it must be written high quality as possible.

Because the quality of any product depends on the quality of the raw materials fed into it, poor requirements cannot lead to excellent software.

Characteristics of Quality Requirement Statements

There are some measures to evaluate if we have good software requirements or not. This section describes six characteristics individual requirement statements should exhibit, while the next section presents desirable characteristics of the SRS document as a whole

1- Correct. Each requirement must accurately describe the functionality to be delivered. The reference for correctness is the source of the requirement, such as an actual customer or a higher-level system requirements specification. A software requirement that conflicts with a corresponding system requirement is not correct (of course, the system specification could itself be incorrect).

Only user representatives can determine the correctness of user requirements, which is why it is essential to include them, or their close surrogates, in inspections of the requirements. Requirements inspections that do not involve users can lead to developers saying, “That doesn’t make sense. This is probably what they meant.” This is also known as “guessing.”

2- Feasible. It must be possible to implement each requirement within the known capabilities and limitations of the system and its environment. To avoid infeasible requirements, have a developer work with the requirements analysts or marketing personnel throughout the elicitation process. This developer can provide a reality check on what can and cannot be done technically, and what can be done only at excessive cost or with other tradeoffs.

3- Necessary. Each requirement should document something the customers really need or something that is required for conformance to an external requirement, an external interface, or a standard. Another way to think of “necessary” is that each requirement originated from a source you recognize as having the authority to specify requirements. Trace each requirement back to its origin, such as a use case, system requirement, regulation, or some other voice-of-the-customer input. If you cannot identify the origin, perhaps the requirement is an example of “gold plating” and is not really necessary.

4- Prioritized. Assign an implementation priority to each requirement, feature, or use case to indicate how essential it is to include it in a particular product release. Customers or their surrogates have the lion’s share of the responsibility for establishing priorities. If all the requirements are regarded as equally important, the project manager is less able to react to new requirements added during development, budget cuts, schedule overruns, or the departure of a team member. Priority is a function of the value provided to the customer, the relative cost of implementation, and the relative technical risk associated with implementation.

We can use three levels of priority. High priority means the requirement must be incorporated in the next product release. Medium priority means the requirement is necessary but it can be deferred to a later release if necessary. Low priority means it would be nice to have, but we realize it might have to be dropped if we have insufficient time or resources.

5- Unambiguous. The reader of a requirement statement should be able to draw only one interpretation of it. Also, multiple readers of a requirement should arrive at the same interpretation. Natural language is highly prone to ambiguity. Avoid subjective words like user-friendly, easy, simple, rapid, efficient, several, state-of-the-art, improved, maximize, and minimize. Words that are clear to the SRS author may not be clear to readers. Write each requirement in succinct, simple, straightforward language of the user domain. Effective ways to reveal ambiguity include formal inspections of the requirements specifications, writing test cases from requirements, and creating user scenarios that illustrate the expected behavior of a specific portion of the product.

6- Verifiable. See whether you can devise tests or use other verification approaches, such as inspection or demonstration, to determine whether each requirement is properly implemented in the product. If a requirement is not verifiable, determining whether it was correctly implemented is a matter of opinion. Requirements that are not consistent, feasible, or unambiguous also are not verifiable. Any requirement that says the product shall “support” something is not verifiable.

Characteristics of Quality Requirements Specifications
A complete SRS is more than a long list of functional requirements. It also includes external interface descriptions and nonfunctional requirements such as quality attributes and performance expectations. Look for the following characteristics of a high quality SRS.

1- Complete. No requirements or necessary information should be missing. Completeness is also a desired characteristic of an individual requirement. It is hard to spot missing requirements because they aren’t there. Organize the requirements hierarchically in the SRS to help reviewers understand the structure of the functionality described, so it will be easier for them to tell if something is missing.

If you focus on user tasks rather than on system functions during requirements elicitation, you are less likely both to overlook requirements and to include requirements that aren’t really necessary. The use case method works well for this purpose. Graphical analysis models that represent different views of the requirements can also reveal incompleteness.

If you know you are lacking certain information, use “TBD” (”to be determined”) as a standard flag to highlight these gaps. Resolve all TBDs from a given set of the requirements before you proceed with construction of that part of the product.

2- Consistent. Consistent requirements do not conflict with other software requirements or with higher level (system or business) requirements. Disagreements among requirements must be resolved before development can proceed. You may not know which (if any) is correct until you do some research. Be careful when modifying the requirements, as inconsistencies can slip in undetected if you review only the specific change and not any related requirements.

3- Modifiable. You must be able to revise the SRS when necessary and maintain a history of changes made to each requirement. This means that each requirement be uniquely labeled and expressed separately from other requirements so you can refer to it unambiguously. You can make an SRS more modifiable by organizing it so that related requirements are grouped together, and by creating a table of contents, index, and cross-reference listing.

4- Traceable. You should be able to link each software requirement to its source, which could be a higher-level system requirement, a use case, or a voice-of-the-customer statement. Also link each software requirement to the design elements, source code, and test cases that are constructed to implement and verify the requirement. Traceable requirements are uniquely labeled and are written in a structured, fine-grained way, as opposed to large, narrative paragraphs or bullet lists.

Guidelines for Writing Excellent Requirements

Here are a few guidelines to keep in mind as you document software requirements.

• Keep sentences and paragraphs short. Use the active voice. Use proper grammar, spelling, and punctuation. Use terms consistently and define them in a glossary or data dictionary.
• To see if a requirement statement is sufficiently well defined, read it from the developer’s perspective. Would you need additional clarification from the SRS author to understand the requirement well enough to design and implement it? If so, that requirement should be elaborated before proceeding with construction.
• Watch out for multiple requirements that have been aggregated into a single statement. Conjunctions like “and” and “or” in a requirement suggest that several requirements have been combined. Never use “and/or” in a requirement statement.
• Avoid stating requirements redundantly in the SRS. While including the same requirement in multiple places may make the document easier to read, it also makes maintenance of the document more difficult. The multiple instances of the requirement all have to be updated at the same time, lest an inconsistency creep in.

By following these guidelines and by reviewing the requirements formally and informally, early and often, your requirements will provide a better foundation for product construction, system testing, and ultimate customer satisfaction.

I’ve read a lot of blogs that talk about what makes a good software engineer. Some are even written in a developer friendly language. But who exactly are those good engineers? Is their existence a myth?

Actually, I guess we see them in an average company every day. Those are the guys who are called company’s star developers. Guys whom we try to analyze their skills and create make them standards to improve product quality. Guys who think before shooting lines of code. Do a design or a general architecture and have a clear rationale behind it. Can answer you why they have chosen this design pattern over the other. Always know that for every design there are drawbacks; however, for their cases the designs they have chosen have more pros than cons. Guys that can confidently say “X” is possible however “Y” is impossible, and even though “Y” is impossible there exists some work around or way to simulate it.

So I have been thinking, why are those guys special? What makes them good engineers, the company locomotive, ones who almost always have answers, ones we go to for the dirty work, ones who influence most of the development decisions?

I’ve collected some points that define some of these guys’ qualities.

They tend to understand the problem statement and the objective behind it.

They first listen to your problem statement, highlight with you the main points, then ask more questions about your motivations. Sometimes problems come in the form of a solution. Those people rarely implement a solution they don’t understand. Knowing your problem and motivations behind the solution, they have a better chance at formulating a better solution and propose a more innovative or intuitive solution.

They tend to think more than write/speak.

Given a problem and a proposed solution this doesn’t mean start coding right away for them. This in fact means setting a high level architecture for the solution if needed. Then setting a software design that goes with the previous design standards set for the project if any were found. They validate their design against some non-functional requirements. Some of the non-functional requirements are set by them. They like to consider the following aspects of a design:

• Extendibility: how will this design scale in case of future needs?
• Maintainability: What is more likely to change in the future? And how to make it easier to change it without breaking the design standards?
• Performance: Will this system be performing under current load constraints?
• Scalability: What about the performance in the future? What will need to be changed in order to meet growing loads?
• Security: Not asked about unless explicitly mentioned. However, they design trying to minimize security risks.
• And the most important part is the design itself. They tend to care about what standards will be used, what design patterns are being used? Is it simple or is it over complicated. Is it usable by developers? Is there any chance that this design will be misunderstood or misused, like can anyone -using the proposed design- get non-fully initialized objects or pass wrong parameters to a call?

If they have the first point into consideration too, they will be able to make more accurate decisions about their design. Since everybody knows no design does everything, they know when they use a static class instead of singleton, that they need free serialization and neglect order of initialization.

They understand their tools and environments and know why they use them.

They understand their environment. They know what operating system they are using. What memory management strategy it uses, and how their application threads are being handled. They know their language and what kind of problems it best suites. They understand how their language manages their classes, properties, variables or constructors. And more importantly, they know what the language drawbacks are; why Java doesn’t have multiple inheritance and how to simulate this.

They tend to be comfortable with many tools and love few.

Since they understand memory management concepts among other programming languages concepts, they can easily use many languages and know exactly what each language is doing with their code. They can take advantage of scripting languages dynamic typing and compile time typing in others. They add properties to objects in a JavaScript code to simulate an adaptor or use the Java generics features like wildcards to make factories. However since they know a language advantages and disadvantages, they tend to lean towards some. There is always a special place in their hearts for some language; maybe because they wrote their first recursive function in, or simply because it has more frameworks and APIs that makes their work easier.

They are never afraid of maintenance tasks, take longer time in them.

Actually, they love to continuously maintain their own code. They understand that they’ve never written a perfect code. And they love to go back and re-factor THEIR code once they learn a new trick. They understand that regular code re-factor is a healthy thing for their code base. Hence, a maintenance task that tests their skills and NOT their patience is always welcomed. In fact, whenever such a task is assigned to them, their concern rapidly shifts from “get this thing going” to “make a design to eliminate the problem and any future similar problems, now re-factor old code to use new design”. This may take more time in a maintenance task, but it sure guaranties that their code base is healthy and future-improvement friendly.

Always reading and learning something new.

They are the guys who visit each others’ blogs regularly. They get their hand on technology previews. They love to check technical articles debating about design choices and understand pros and cons. That’s why they are the guys who tell you to check out some build of Firefox because it now supports some new standard from HTML 5.

Always trying new things they read about.

Well I forgot to mention they are not just reading, they actually try firsthand what they read about,. and send the authors about problems that faced them. They don’t report inconsistent fonts like your typical GUI QC engineer, they report a failure of integration between modules in a specific environment.

I was once doing an interview and was asked how I see myself in the next five years. I replied I see myself as a Software architect and a consultant. The next question was a hands-on-architect or a PowerPoint one. The difference was obvious. Sometimes you work with an architect that -ignoring all natural physics and even some chemistry laws and theories- draws a line between two modules claiming that now they can communicate seamlessly, though a hands-on-architect would never do that without actually inspecting communication interfaces, protocols, parameters and constraints, hence; defining additional adapter modules or an additional tier for communication or simply discarding the idea because the interfaces doesn’t allow required information transfer or the performance for these interfaces is less than required.

They give a hand whenever possible, rarely takes one.

A successful leader is the one who helps his team succeeds. Same goes for team members, while those guys always try to find solution themselves and exhaust every known search engine and book for answers. They don’t quit easily and their pride is a very important aspect. In their search for answers for a given problem, they find answers to other problems. Usually their search benefits their team mates more than themselves. However, the knowledge they gain is far greater than that of text books. They actually gain others’ experiences and build on it. In their research time, if they are not searching for solutions, they are trying new things.

They are mostly proactive.

No one re-factors his code, try new stuff or search for solution, and is not a proactive person. Those guys believe in actions more than reactions. They are not afraid of a code re-write if the situation calls for it and never afraid to open their dusty old code and remove the spider strings. They like to try new stuff and invest in technologies that might not work for them in the end.

I think that’s why some are called a better Software Engineer. However, I guess I missed other points. Share your thoughts; what else makes a good Software Engineer?