So what's your priority?

In the fast paced world of software development, sooner or later you or someone on your team will find a situation where they are faced with multiple tasks, and competing priorities.   So what does a person do when an urgent list of changes to a software under development is received?   Then what do you do when the expected time to deliver these features appears to be something rather aggressive?

Let's take a step back for a second to discuss the requirement process.  Often requirements are not as detailed as necessary to begin to design or codify.   Sometimes requirements may be in a list form, they may be rather obvious, but more likely they are obscure, cryptic, or down right confusing.   Because of this, very often there is a necessary feedback loop between the team and the client just trying to make sure they understand the change, and the impact it may have on the system.

This back and forth, haggling over specifics, and gaining enough understanding to model the process necessary to be implemented can be very time consuming, and often the hardest part of the software process. Customers do not always have the computer knowledge to give sufficient feedback about what they write, and as a developer it is our jobs to not just verify that we are building the software correctly, but even more critical, we must validate that which are building actually meets the needs expressed in the requirements.

Often the understanding of a requirement will morph over time, but for simplicity's sake let's assume for a moment that the haggling over the requirements has already taken place.  So your team is called into a rushed meeting to discuss a list of changes.  The manager describes the ten items that need to be implemented, and expresses the hope that it can be done in a short amount of time.  For sake of argument lets say its a week.

Immediately the issue of time and priority may come to the forefront.  If there are ten changes to a system, ten changes that do not necessarily 'interact' with another or depend on another, then how do you prioritize them?  Depending upon what model your process is based upon the answer could vary.  It may be the Project Manager who sets these priorities, or in a more agile environment it could be the customer, or the person designated as the 'product owner' within the team.

So the team after a little debate comes to the decision, much as they might like to pick and choose which pieces to do in what order, they need one more layer of feedback about the requirements, what is the order of priority for these changes.  Given that the team is taking some measure of risk trying to rush these ten features into the system in a week's time, they believe that this risk would be easier to stomach if they could impose some logical order to implement the features, so that if the time should prove insufficient, they could at least be sure to have the  most critical features done and deployed.

So what do you think the response would be?  Hopefully you'll get a list of points itemized from one to ten giving a clear order of development and importance to the customer.  That would be the ideal, but what if the list comes back with six of the ten items listed as priority number one, and the other four as priority number two?  I posed this question on Twitter.

I received a few different responses two of the more interesting ones were from Stephan (@S_2K) "Everything is most important. " Morgan Ahlström (@Morgsterious)  replied with the understanding words "That noting is REALLY important."  These were very much my same sentiments when I pondered this question.  If someone cannot distinguish a hierarchy between two things, let alone ten things, how then can you know which items are of most importance and tackle those ares of the software first?  Even if you have multiple team members, it is only natural that some components may still have higher precedence.  


So what do you do when you have this sort of situation?  My hope would be that enough time would exist to push back for further definition of the structure of the requirements.  However, given that the customer might not be as eager to be asked the question a second time, or might not be as readily available, the team is then left to its own deductive skills to try and figure out the proper order to do them in.   This is where knowing a bit about potential dependencies within the requirements could lend aid into determining an order of construction. 


Nevertheless, it is still highly probable that there can be no clear prioritization gleamed from this answer.  With time being ever more tight then the team is left to its wits, and knowledge of prior conversations to try and 'best guess' the order they should tackle the changes.   In the end the team might complete all ten, or they might completely only a handful of the tasks.   In the later situation, the customer might then push back and ask why they completed one task but not another.  The team then can remember that it didn't get the accurate feedback it requested on prioritization, and could provide this as reasoning for the order they had chosen.


The customer might not like that sort of response, but sincerely in the absence of information, it becomes better to complete at least some of the work, even if you do not know how much, or what order it should be done in. This may not be an ideal solution, but it should be evident from this how important communication with the customer must be to ensure accurate building of the software and the timeliness and sequence of delivery.

Some thoughts about Version Control

In my time as a software professional I have seen many systems for maintaining and tracking changes to code in progress.  Whether this is the archaic and I hope no one ever really uses this on a real project practice of passing along zip files of changed code with comment mark-up to indicate where changes were made, or to full featured source control solutions, like subversion, team foundation server, or git, every project at some point or another will have to make a decision on how to handle these files.

I could spend time dealing with the importance of choosing any source control solution, but that's not what this post is about.  Instead I'd like to take a moment to describe some of my experience with source control solutions.

In general there are two sorts of source control mechanisms, one is like that used with Microsoft's Team Foundation system (and before it Visual Source safe an incremental check out/check in system, and the other is a check out the code base, and commit/update to get/add the latest changes to the current working version.    There are pluses and minuses to both schemes.  The incremental check out/check in system really feels like a pull system.  While you can download the latest tree from a base directory, to make changes, and have them be saved with out the IDE screaming about read only or protected files, you have to make a point to check out in essence pulling on TFS to make the file ready for editing.   Team Foundation Server (TFS) allows you to do this in an exclusive mode, essentially locking out any other attempts to check out and change the file by other users, or a less prohibitive more shared lock.  

I've only had the privilege of working on a single project with TFS thus far, and that project relies on the exclusive kind of check out system most of the time.   This means that if a developer needs to make a small change to a file that you are working on, he will have to communicate that need to you, so that you can then do a hand shake of releasing the locked edit, so that the change can be checked in.  It can be a real pain at times when you want to try a quick fix and the IDE prevents you at times from trying something simply because it's marked as 'read-only'.  It provides a benefit in that it limits the number of files you might accidentally touch which can be a blessing at times.  It also means that anyone trying to check in another fix may not be able to do so while it is held checked out, and as has happened to me a few times, sometimes files in a project may get checked out by the IDE automatically even if you did not intend it so.

The other form of version control management is the style for which Subversion has become known. It is in essence a more push style of architecture, where by, you can check out an entire source control tree (much like getting latest for any particular folder), and then have significant freedom to make changes, erase a file and refresh/revert it from the last commit, or even make a series of changes and check them in one after another.  The draw back of this system, is that because anyone can edit, there is the possibility of files getting more and more out of sync from the base or trunk as it is called in subversion.  This can present problems when during a commit a major conflict arises trying to reconcile differences between the two files.    In my experience though, if used judiciously and kept up to date and committed as often as necessary, these conflicts can be minimized fairly easily.   Subversion also has the bonus in that it is portable to other operating system types, and is not dependent on the windows/.Net stack as much to function.

There may be other tools that fit your needs better, Wiki's can be edited inline from a browser and keep good version tracking of each meta page, content management systems like Share Point can allow you to track updates to your requirements, contacts, or serve as a portal for storing key documentation for a production.  Whichever tool your team chooses for source control, it is critical that your entire team is on board with its function, and regular use to help avoid major headaches between builds.   The value of source control is manifest in how it allows teams to track branches of in progress development code, tag certain releases for easy comparison later, and giving a history with comments about the update and logs of the files that have changed.  This logging function can be of great value when trying to track down how a particular strain of bad code may have made its way into your product.

Then some source control systems allow you to track the progress of development from requirement, to deployment.  Team Foundation Server has these features out of the box, while open source tools like Subversion require other components, for example TRAC, to help track the progress of development.  I hope that whatever your team chooses to use, that you will find the source control to be a great asset, that helps facilitate your development needs.