Tuesday, 28 August 2012

"Is Everything Alright?” may not be Alright

Incremental deliveries are not just good enough. You should ensure that they are really adding up to the Constructive feedback in achieving your long-term goals, than just aiming for "Everything is Alright" with every incremental delivery.

When our team first started with the Iterative model of development, the information we used to exchange with the customer, used to be something like this:
  • Implemented ABC, XYZ, … features
  • Fixed the Bugs: XXXX, YYYY, ….
Okay, Alright(X) In the follow-up calls with the customer, we used to ask very generic questions like “Is Everything Alright?” OR “Are there any issues?” and we would be eager to hear from the customer side “Okay, everything is just perfect”. We didn’t use to pay enough attention to ‘How they were/should be testing the deliveries'. Often, we used to have a demo, but one cannot cover everything in a demo.

The customer came back much later in the project cycle reporting a few serious bugs which should have, ideally, been reported before. They cost us more considering the amount of refactoring and the other overhead (planning, prioritizing, additional testing etc.) required. This meant that the iterative development didn’t completely serve its purpose, though it made a few things better in handling the project internally.

It took us sometime before we realized a few facts:
  • ‘Incremental Deliveries Are Not Just Good Enough’ and we need to do everything right to ensure the customer would be testing those deliverables diligently in providing the Right feedback at the Right time.
  • Don’t even aim for “All is Well” reply from the customer in the beginning cycles of the project. It is not something to cheer upon. You should welcome Specific and Tangible feedback and Rework but don’t try to avoid it. Anyways you would be working on it later and you cannot escape from it.
  • Also, we became conscious about the addendum information that we had to deliver along with the incremental deliveries.
-Exact list of Testcases (Acceptance Tests); Scenarios that the customer can explore.
-What's Pending (Something for which you delivered a temporary or an incomplete solution) and ‘Known Failures’
-'In Process’ user documentation, if any
-Any other useful notes, that is not taught by your Agile coach but contextual.
  • Welcome those short-term hits for the long-term Quality goals.
  • Communicate ‘What has to be Tested’ along with ‘What is Added and Fixed’ because ‘the later a bug is caught, the costlier it is’.
  • ‘You test it Now’ is more practical than ‘You should have reported it before’.

When your requirements are highly unstable and volatile, use the incremental deliveries as artifacts to decide the direction you need to travel than just an instrument to validate what was done. This simple perception change brings in a lot of difference in your approach and methods you follow to receive the feedback. The same might be applicable, but to a lesser degree, in the scenarios where your requirements are fairly stable.

"Remember that the incremental deliveries are, in general, the production quality code drops and not miniature or prototype versions". So, even the validation has to be done on the similar lines. 

Sometimes, it is important to know ‘who would be testing your deliveries from the customer side’. It would be very useful getting in direct contact with them rather than getting the second-hand information from someone who is working with you on the requirements and estimations etc.. This will help process the information better and faster.

Verification QuesionsAre you ensuring that your incremental code drops being tested diligently from the customer side?

Are you talking to the right person from the customer side who is validating your deliveries?

Is the feedback you are receiving ‘Specific and Constructive’?

(Attribution: Images on this post are downloaded from FreeDigitalPhotos.Net)

Wednesday, 22 August 2012

A few comments on Comments



You are not the owner of the code that you write. The owner is always the organization who you are working for, or the customer who you write the code for. So, please write proper Comments with your well-designed and beautifully-working source code, so that it helps you and other developers during and after the development cycle.


Let us talk something specific than general suggestions.

What does proper mean here?
Is it proper style and syntax?
Is it writing in proper place?
Or Is it writing proper text?

So, how about a few comments on Comments:

// Don’t hesitate writing a long Comment when it is necessary.
// Don’t sacrifice Comments for a beautifully-looking code.
// ‘Purpose’ of a Comment overrules ‘Beauty’ of code. 
// Don’t just explain the WHAT part but explain  the WHY part.
// Most of the times WHAT is more obvious with proper coding standards.


// Sleeps for 5000 ms

The above doesn’t serve any purpose. Rather, something similar to the following comment would serve the purpose right.

// (What) Allow time for the input processing. 
// (Why) From the testing performed, it usually takes around 2000-3000 ms in normal
// workload scenarios. So, using a 5000 ms delay to be on a safer side, considering
// significantly higher workloads and at the same time not slowing down the processing time.
// (Why for future) When we support xyz interface in future, we need to revisit this interval.
// We need more time delay to be allowed on xyz interface.
// So, the performance with this interface might be a bit compromised.

// Don’t add Comments which are very obvious.
// Comments and Coding Standards are Complements but NOT
// Replacements to one another.


// Copy all elements, field by field, from source to target.
src = getNextSrcElement();
target = geNextTargetElement();
// copy src name to target name
target.name = src.name;
// copy src title to target title
target.title = src.title;
//Allowed bonus is 50% more in target per the following requirement
target.bonusLimit = 1.5 * src.bonusLimit;


// Necessary Comments are MUST than GOOD-TO-HAVE.
// Working-code is a subject of your Design and Coding skills and it is for your
// Compilers and Computers;
// Explaining-code is a subject of your Comments and Coding Standards and
// it is for us, the Human-beings.

Fixing an ‘Undeclared Variable’ error is a MUST situation that your compiler creates for you. Fixing an ‘Unexplained Code’ is a MUST situation that you need to create for yourself.

I don’t believe poor Comments have impact on Quality !!! ??? They are just plain text.
Man with a Question
Yes, they may not have immediate or direct impact and that’s probably why some developers safely put them on the back burner. But in the long run, here are some of the bonus items offered by an ‘unexplained’ or ‘improperly explained’ code. :)
-- Removing/Modifying a line of code which shouldn’t have been and thus attracting regressions.
-- Longer cycles to understand the code as part of code reviews, bug fixing, code extensions etc..
--- ---------------------------------------------------------------------------------------------------------------------------

So, the inference is:
// Our goal is not 'writing Comments' but it is 'writing some useful information, which cannot be conveyed just though the executable code, in the form of Comments'.
// Write 'Necessary and Sufficient' Comments maintaining the balance between Readability and Maintainability of the code.
// Once you have written the Comments, read them 'from the future' point of view and 'from the eyes of the other developers' to ensure the Comments are serving their purpose right. If you want to understand ‘why’, try reading your own code (without comments) that you have written a few weeks back.

Verifying Questions
Does your team understand what 'proper' Comments mean?

Does your team understand the role of proper Comments in the long run maintenance of the code?

"Let us not forget the basics even when we are doing the amazing things."

"Attribution: Images on this post are downloaded from FreeDigitalPhotos.Net"

Tuesday, 21 August 2012

Business-Driven OR Fact-Driven Design

It’s not always the technical reasons that drive the design decisions. More often, they are business based too. 'What design decision are you making' should also factor in 'When are you making the decision' and 'Why are you making the decision'. This is one of the areas where an experienced project manager or an architect can guide their technical teams in making those right decisions - means just right for the time and the context. This is what we can call as a Business-Driven-Design or a Fact-Driven-Design.

There are two extremes as far as our approach to design is concerned:

Piecemeal Approach - Not paying enough attention to design and writing code on a piecemeal basis. It can be due to lack of necessary technical expertise or due to high misinterpretation of the Lean Development concept and thus making it more leaner than it has to be.
[This leads to highly unmanageable and poor quality code and will have impact during and after the development cycle]

Best Design Approach - Trying to apply everything you learnt about 'Software Design' and 'Design Patterns'. Well, I was not an exception here. :)
[Possible under all imaginary and ideal conditions like - you have unlimited time OR you do everything right to the perfection the very first time. Practically, it is never possible.]

Common sense and business sense play their roles in coming up with a design that is ‘necessary and sufficient’ with reasonable trade-offs made. In other words, it is about the art of looking beyond your code. 'Trying for a right design at a wrong time or for a wrong reason may turn out to be more dangerous than a poor design.
What When Why

Invest in better design only if it is necessary and only when it satisfies the simple rule of ‘Return on Investment (RoI)’ .

For example, assume you are developing a tool for some kind of Tax Processing requirement, supporting two different Tax Implementations, say Sales Tax and Corporate Tax.
-- If you are sure that no other tax types will be added in future, do not try to get the best design in terms of abstractions and reusability. It is not necessary though technically right. Handle them with simple if-else logic wherever you can, after having just-sufficient abstractions and reusable code implemented.
-- On the other hand, if you know there are going to be multiple other tax types supported, handle them better in terms of design. It is technically right and necessary as well. Even, this helps you make right decisions on all other connected things like whether to use a radio button or a drop-down box for selecting the Tax type on the front-end.

  • Temporary trade-off
For example, if you are about to make a code drop and you have noticed a 'non-trivial but useful' design change to be made, do not handle this in haste. Your decision might be right, but not the time. Rather, push this to the next iteration, probably as a first things to do.

  • Permanent trade-off
For example, if you are product based and your eye has caught a design improvement to be made right before a release, let the technical guy inside you sleep for some more time. You are too late, though you are right. The best design 'now' is the design that is already working. This is where ‘Don’t change working code’ makes sense.
[If the impact is significant but not severe (like a typical performance issue), it can be handled in a follow-up release.]

It is mixed with what-to-do and when-to-do.

-- Why do I need to design this way or that way?
-- What is the benefit for me or the impact on me during the development cycle? (Well, it is not about your performance appraisal and pay hike. :) )
-- What is the value/impact for the customer after the delivery?

If you don’t have enough time or enough data and you have to choose between 'better design' and ‘working code’, it makes perfect sense to prefer the latter. Spend the time you have for doing better things like - testing your code properly and fixing any potential bugs.

Questions to AskAre you making the right design decision (to-do or not-to-do) at the right time?

Are you considering the 'value proposition' in making the design decisions?

(Attribution: Images on this post are downloaded from FreeDigitalPhotos.Net)

Tuesday, 14 August 2012

Bend the Rules(safely) to Win the Game

When your team is on to executing a project, there is always a task-breakdown (Milestones->Features->Tasks etc.,) exercise done. The way you do the task decomposition is, most of the times, influenced by how you/your team had done it in the previous projects. But, as your project goes on, there might be some feedback - be it internal or external - that helps you revisit the effectiveness of your task-breakdown. This might enable you identify the opportunities to execute the project better and faster, yet respecting the sustained development. 

This is some lesson which our teams learnt by practice when the things forced us to do so. Here is an example of how we learnt this hard lesson:

Quick background of the project...
  • The project was about migrating a System-level application, from one hardware architecture and OS to another hardware architecture and multiple other OS platforms. 
  • This was the project which had the potential to change the fortune of our company (in fact, it did) and could help us move to a “Next” level in the business. Thus it carried a greater business importance.

We were thinking, we were doing just right...
  • The major portion of the “Task Breakdown” in our project plan was done based on the “Functional” features of the product. “Task Distribution” among the team was done based on this. 
  • We were doing incremental code deliveries every 2 weeks or so. We were almost 30% into the project timeline (excluding the time we spent for the initial Inception and Elaboration activities in the first few weeks). The line items on the MS project planner were looking GREEN. :)

The customer’s feedback that made us rethink our approach...
FeedbackThings were looking very bright and we were thinking that we were on the right track, until we got this message from the customer side on a fine day.

"The customer, in his feedback, politely screamed that they were not so happy with the project progress per the validation metrics they were using". 
  • The customer stated that, as per the Automated testsuite that they were using for measuring the project progress, hardly 8-10% of the testcases were working whereas we were almost 30% into the project's timeline.
  • The customer’s concern, in this case, was not about the Quality but the question raised was whether our team would be able to complete the project on time.
  • It was HIGH time that we had to win the customer back in the game. Definitely, and without choice, we had to do something about it.

Then, how did we react...
Run Around ClockAn immediate jerk reaction would have been that the project manager asking the team - ‘Let us slog it out, and bridge the gap, come what may and I promise you late-night dinners:)’. This would have made everyone run around the clock. But our team, guided well by our project manager, did something different. What we analyzed was the fact that we could do the work breakdown and distribution in a different way.

  • There was considerable overlapping(duplication) of efforts with individuals owning the tasks based on “Functional” Features. This meant that more than one engineer were working on migrating the same source code files at the same time.
Task Breakdown
  • The corrective step taken was to break and own the tasks based on the 'Sourcecode files' to enable us perform bulk modifications in an iteration. We had enough technical details for doing this and I am not mentioning them here.

  • Now, our iterations became slightly longer because we needed to have enough room to test the bulk code modifications before delivering the code drops. We explained this to the customer and got their acceptance as well. Of course, “All conditions Applied” works neither for the customer nor for the service provider. There needs to be reasonable trade-offs made.

With this approach, we bridged the gap that we had with respect to the project progress and also continued the same approach for the rest of the project duration.

What is meant to be conveyed through this example?
  • Breakdown-into-Tasks doesn’t have any standard formula. As long as your approach to this is logical and your team knows how to validate, it is right-for-the-project and right-for-the-context.
  • Practically, you cannot get all your practices defined to the perfection when a project starts. You just cannot get started with too many variables in hand. Also, the demands of the project are always different at different times.
  • It is about your continuous attention to the details and how do you constantly tune your approach to what-is-more-apt. Probably this is what “Responding to Change” was meant for this specific instance explained.
  • On top of all, if you are a project manager, involve your team in making important decisions that would have impact on both “Customer Satisfaction” and “Team Satisfaction”. In this case, if the project manager had a made a decision to “slog it out”, he could have still won the customer but at the cost of the team satisfaction.

Is your team's task-breakdown the best during all phases of your project? Is there anything that can be done better?

If you are a project manager: Are you involving your team in making those important decisions that would have impact on sustained development?

(Attribution: Images on this post are downloaded from FreeDigitalPhotos.Net)

Friday, 10 August 2012

Is Agile limited to Development projects?

Can we practice Agile in a maintenance project?
Can we follow Agile in executing a migration project?
Can we use Agile in …?
Is Agile limited to only development projects?

What drives us to adapt to a new process or alter an existing process? It is always this golden objective - Quality. Different projects carry different Quality criteria. Before trying to find an answer for “How do we deliver Quality in this project?”, we need to answer “What does Quality mean for this project?”

Let me try to illustrate this with an example of how we implemented Agile in a Production Support project.

*A quick background of the project:
  • The project was about handling the business-critical Production Support for a telecom client. This was handled offshore completely.
  • The customer’s business was tied up with different Service Partners to provide end-to-end service to their customers. Taking this to technical terminology, it was all integrated on an SOA based architecture.
  • Often there were service failures due to various Technical and Operational reasons and our job was to analyze those failures and handle them offline.

ID-10091674*So, what was Quality meant for this project?
  • Reliability - As we worked on the production issues, it was a MUST that our solutions were highly Reliable.
  • Better and Faster - It was DESIRED that we provide continuously better and faster solutions, considering the huge customer-base of our customer.
  • Timely & Consistent communication with the business users - We had to work with the onsite team, working on the other side of the globe. So, our communication with them had to be -
    • Timely - Delays, due to timezone differences, should be minimized so that end-customer concerns are addressed at the soonest. Not a typical requirement in Development projects.
    • Consistent - Our communication with the onsite team should always reflect that either we know something or don't know something as a Team but not as Individuals. It is highly DESIRED from business point of view.
  • Continuous Learning of the System: It was a complex system and so it was DESIRED that we learn the system better and better as we go dealing with various issues.
  • Customer satisfaction through End-Customer satisfaction: "Our customer will be happy, if their customers are happy". This is the simple business rule that we always respected.

*So, how did we implement Agile here?

The daily Scrum meetings played a major role here and this is how we tuned our Scrum approach in dealing the issues reported by the end-customers.
  • What is New (Either we didn’t handle this before or this is slightly different from what we handled before)?
Can we handle this ourselves? If so, who is the best person to handle or help? Or, do we need to approach the onsite team? (Providing ‘Reliable’ solutions)
This is towards the “Reliability” criteria.
  • Are there any Bulk (High in number) and Repeated (being seen more often) issues?
This is towards identifying the need for building new tools or modifying the existing tools (Automated or Semi-Automated) to meet “Better and Faster” criteria.
  • Any escalations?
Business SLAs take priority over having a perfect solution (‘End-Customer satisfaction’).

-- Timely communication with the onsite team and continuous learning of the customer’s business were the by-products of these discussions.

-- It also helped us address the Single-Point-Of-Failures (SPOF here is Knowledge being confined to individuals). SPOF would, in general, have more impact in a Production environment than in a Development environment.

-- We never discussed the issues that were routine and they were far off the Scrum meetings. Our meetings intended to be meaningful and action-oriented. We didn’t make them daily status meetings. Our team was enabled to take care of the routine issues by themselves.

What is meant to be conveyed through this example?

-- Challenges are different for different projects. Some projects would be more about ‘What to Implement’  whereas some projects would be more about ‘How to Implement’?

-- Our project was more about ‘What to Implement’ than 'How to Implement’. I must say that technologically it was not so challenging but we were constantly identifying and implementing the tools(Java/J2EE and PL/SQL based - just to add) that create value for the customer's business. So, it was more of a business challenge.

-- There was no concept of continuous delivery, iterative development, early feedback etc. in this particular customer engagement. From a different sense, our solutions were reaching to the customer on a daily basis (unlike in a typical Development project).

-- To state the fact, it took us some time to figure out what exactly were the expectations and the Quality criteria. Every project would see this phase, particularly when your team is handling a new type of project. Some conscious experiments and trial-and-errors are required to get on to the right track.

The subtle message that is intended to be conveyed is - ‘Work on identifying your Quality goals and customize your practices to achieve those goals’.

What are the Quality objectives of your project? How is it different from the other projects that you executed?
How can you apply the tools(practices) available for the job-in-hand? What works for you, and what does not work for you?

(Attribution: Images on this post are downloaded from FreeDigitalPhotos.Net)

Monday, 6 August 2012

Process is a way, Practice is the key

“Name of the process cannot make any magic by itself. The set of yet another BIG terminology in the process documents is not just good enough to reach your Quality goals. It’s all about your practices and how you tune them to suit the long-term(final project deliverables), short-term(iteration or sprint) and immediate(problem-in-hand) needs of your team.”

Here are some practices that can be promoted and encouraged along with the so called process improvements.

Ownership & Contribution
“Everyone cannot be good at everything. If someone is good at thinking of a better design, someone else will be very good at writing some complex string parsing logic. Respect Integration of Skills along with Integration of Tasks.”

  • Every individual takes the ownership of delivering the tasks assigned to him.
  • Everyone has the right to seek help from others when needed or offer help to others as desired.

Your Boss need NOT be right all the times
  • Okay, it’s not that “Boss is Never Right” :)
  • Create an environment where healthy debates over project issues/technical options take place with Quality of the project as a common goal.
  • Manager contributes but doesn’t impose his ideas on the execution though he solves the conflicts. Team’s agreement is always respected.

Meaingful Meetings
Break the rules. 'Getting the job done' is the ultimate goal.

(x)Scrum is not more than 15 minutes: Not correct.
  • As long as the team is discussing something useful that adds to the Quality, a few minutes extra is worth it. Remember, Agile is basically about minimizing the rework and waste and scrum is a very good platform for this. There is no point being too strict on this time.
  • Remember that a considerable part of a typical software project time/cost is spent in rework and bug-fixing if the teams are not properly collaborated. Do the right thing at the right time.

(x)Everyone should stand in the Scrum: Not necessary.
It’s okay as long as everyone participates actively.

(x)Technical issues not to be discussed: Misinterpretation.
Technical issues are always on the top for discussions. Yes, you are right. Only those strategy and planning meetings cannot create working code.
Discuss things like “HashMap Vs HashTable” that caused a bug in your code; the interesting thing that you have come across about some String parsing logic that everyone should make a rule to follow; Revisit exception handling in the code developed so far with a hint from some bug encountered; Show that piece of code if it helps the team; Anything that is a parameter for the top-most goal - Quality.

The guideline is “your learning” should add to the “quality of the team” and not just the “quality of the individual”. There is no point in the same mistakes are getting repeated with different individuals at different times.

(x)One cannot speak for more than 3 minutes: What purpose does it serve?
If someone has something important to update or share, let him take the time he wants. The intention is to serve the purpose right. Don’t use ‘Stop-Clock’ methods. Maybe the issue he is encountering might lead to uncovering a major product bug which is worth fixing now than being reported by the customer.

Wisdom of the Group
“Okay, YOU are good, but WE are better together”. Different individuals bring in different insights. It’s not that everyone is to be on every task though.

Don’t wait for the scheduled meetings
If there is some potential bug or logic flaw that you have noticed, stand-up and speak it loud. Often, informal meetings are far more effective than formal and scheduled meetings. That is because informal/at-the-desk meetings are mostly about something “specific” and thus very much focused.

Knowledge Sharing
"Share the knowledge and that’s how you got it. Scrums are generally a good platform for this, though not limited to."

  • Create a platform where knowledge sharing happens on a continuous basis, without saying and without planning.
  • Knowledge sharing is not just those PPT presentations.

Set aside the rules, Do-What-Is-Needed
  • If there is an erroneous code that has to be corrected, do that NOW before you build something more on that erroneous code. Otherwise you are consciously adding more bugs to be fixed later.
  • Relax your sprint backlog spreadsheet before the flaw creeps in other places. Communicate with the other stakeholders accordingly as needed.

Be a good listener, pay attention to what others speak
Applies to everyone in the team. No more explanation is required. Don't forget that 'good learning skills are part of good communication skills'.

We need to understand the fact that none of these principles are meant to deal with the incompetency of the team members. It is all about complementing the individual efforts to get the job done more effectively as a team. It’s about how you can demonstrate 1+1 = 3 (Complementing rule) than 1+1 = 1 (Overhead rule).

As one can depict from the above, these guidelines are not a matter of documentation but a matter of practice. Things that are understood well can always be implemented well.
Is your team working as a Team?
Yes, you read it right.
Is your team working as a Team?
(Attribution: Images on this post are downloaded from FreeDigitalPhotos.Net)

Thursday, 2 August 2012

Discover the Design, Don’t Impose

"When we are asked to carry out the software design, the thing that immediately strikes to some of us is - a big picture of Design Patterns, Block Diagrams, UML Diagrams, CASE tools etc. And this is where some of us either shy away from or misinterpret the design job. But design is mainly about our approach to the problem and all the above are merely tools and means that may complement the job."

Let us look into why is that so?

In the article “What is TDD made for?”, we discussed the approach to TDD by doing a small exercise on “building an elevator system”.

Let me copy & paste some text from that article for our quick reference:

What are the different requests and how they need to be processed?
(External Request) Elevator has to go to a floor if there is User request from that floor.
----Elevator has to move UP if the request is from an upper floor.
----Elevator has to move DOWN if the request is from a lower floor.
(Internal Request) Elevator has to go to a floor if there is User(inside elevator) request to go to that floor.
----Elevator has to move UP if the request is to an upper floor.
----Elevator has to move DOWN if the request is to a lower floor.

When does the elevator stop?
----Elevator has to STOP at a floor if there is an external request or internal request to stop at that floor?

What happens when the elevator stops at a floor?
---- Open the Door
---- Update the internal request as DONE or DISCARD.
---- Allow time for passenger to Get-In and Get-Out
---- Handle max-load checking, if any
---- Close the door
---- Update the external request as DONE or DISCARD.
---- (Well, I am not writing all other features (light, fan, displays etc.) of our modern elevators as we are not really going to write the software here)

Well, this has also ended up as a TODO for us but we have added very good set of testcases coming up in the form of “executable specifications”, and what do good “executable specifications” do? They feed to the design and that’s what has happened now – we need another Black Box((a decision-making method) to decide whether to move up or move down. Also, we have identified the parameters(variables) that these decision-making methods need.

Along with this, we have identified different actions (Just execute them – moveUp, moveDown, Open, Close). Also, we have, almost, identified the Data Structures to store the User Requests (Internal and External). Overall, our skeleton code is pretty much visible now.

 Now, let us analyze what we have done purely from a design point of view.

The first step in design is problem analysis - Get it Right in Plain Text.

If we look at the above example, Software Design can be seen as a hidden characteristic of a given problem. The more we try to understand the problem behavior and its constraints (may be you can formally call it as analysis), the better input for the design comes out. Thus the design is discovered than applied.

--Let us not try to solve the problem before understanding it. A problem that is well understood is half-solved.

--Problem analysis doesn’t have a language or technology associated with it. It is merely to do with our cognitive (analytical and reasoning) approach which is always of paramount importance.

--A good problem analysis would give us better requirements for the design.

Here, in this example, we have derived the following design requirements in  a plain text like this:

---- We need "decision making" mechanisms for:
------- Deciding the Direction the Elevator moves
------- Deciding whether the Elevator stops at a Floor

---- We need "action" mechanisms for:
------- Open
------- Close
------- moveUp
------- moveDown

(Please note that the list above is conceptual, not complete)

The next step is program analysis - Get it Right with your technology.

Now that we know what is expected out of the design, it is the stage for the program analysis - how do we implement the design in our programming language or with our technology, and this is where our technical skillset comes into picture.

For example, once we have understood the basic in-built design of the above elevator problem...

---- If we are implementing in a procedural language, we would probably be passing different datastructures from method to method or probably handle them as global variables or something similar, and read and manipulate them from different methods.

---- If it is OOAD, all the above actions would be encapsulated in an Elevator Object and with our problem analysis, it has already come out as a State Machine Model for us.

So, the design has to be seen as a problem analysis followed by program analysis. Merely knowing a set of design patterns or frameworks cannot make someone good at design. 

It’s about a smooth transition of a business problem into technical problem and then to a technical solution by applying analytical and reasoning skills.
Of course, there might be requirements that are technical in nature where our problem analysis and technical analysis may overlap to some extent but our logical approach would be the same. Same goes with the requirements that are high-level where the design decisions would be of the nature like - which WebService to use or which XML Library to use etc.

What if a proper Problem Analysis is NOT done?
--If a proper (I'm not saying perfect) problem analysis is not done, we are adding more variables to the equation. We are mixing up number of business logic variables and programming logic variables. And I don't need to explain further on what it costs.
--There would be considerable refactoring and rework done adding to longer implementation cycles.

Has your team discussed the problem enough before discussing the solution(design)?

Are you ensuring that your team is doing enough exercise to get the 'design requirements' in plain text?

Is your team doing a smooth transition of problem to technology, than jumping straight on to a technical solution?

(Attribution: Images on this post are downloaded from FreeDigitalPhotos.Net)