Rob Kraft's Software Development Blog

Software Development Insights

Archive for the ‘Project Management’ Category

Mastering Software Development

Posted by robkraft on May 31, 2011

To master software development you must know many things more important than writing code.  To get it right, with optimal efficiency, you
must be good at identifying the best solution to your customer’s needs.  You must be good at choosing technologies to use to create the solution.  You must be good at implementing those technologies.  You must be good at identifying what is most important and valuable to work on at every moment.  You must know when to take the time to learn a new skill or new tool instead of using skills and tools you already have mastered.  You
must know how to set customer expectations about the features and the delivery schedule so that will not be surprised at any point or get less than they desired.  You must know how to communicate with clients the estimated cost and value of alternative solutions so the client can make the decisions.  You must know how to estimate closely the cost and benefits of different alternative approaches to a solution.  You must write code that is easy to maintain.  You must be sure your code works as designed, desired, and that it meets requirements.  You must write code that performs well, is free of major defects, is free of security holes, and follows industry standards and government regulations.  Your solution must be easy
for your customer to deploy, understand, and use.  You must master all these things to master software development.  And then, you have
only mastered software development when you are the only person on the team.

When you are a member of a team, or a leader of a team, you must master many more things.  You must understand how to evaluate alternative architectures and guide the team to selecting an acceptable one.  You must know how to evaluate the mood of team members and address emotional issues.  You must know when and how to allow sub-optimal code to enter the solution in order to reduce the stress and anxiety of a team member, or because a team member does not have the skills to complete the code in an optimal fashion in the desired time frame, or because you don’t want to spend the many hours trying to explain why one design is better than the other, or because you need to bring a team member up to speed on certain technologies.  You must know how to help the team identify what is most important to work on.  You must know how to help team members evaluate their own skills and know when to ask for assistance.  You must know how to motivate and lead team members to take ownership of the code and to write quality code.  You must know how to help team members prioritize the work to be done and prioritize features to optimize the work flow process.

Do you get the drift?  To master software development, you must be exceptionally lucky.

Posted in Coding, Project Management | Leave a Comment »

Features are never complete! So stop tracking them like tasks!

Posted by robkraft on January 10, 2011

Have you ever participated on projects in which you implement partial features? I do, all the time. I understand why we do this:

  1. The feature is good enough for shipping and it is more valuable to work on other features rather than complete this one
  2. We overestimated the work involved in this feature and are going to release just a partial feature to meet the most immediate needs
  3. We lost resources during the sprint so we could only complete part of it.
  4. The product owner changed their mind about certain aspects of the feature.

The thing that bothers me about this is that we cannot mark the feature done. The feature lingers in the backlog partially completed; or we mark the feature completed and spawn a new feature to include the aspects of the feature left out of our original desire.

But today, a revelation! Features are never done! Just as a product continues forever and is never 100% complete, every feature continues for ever and is never 100% complete. We should not expect a feature to be “complete”. So we should stop using tracking systems to track features to completion and instead track features the way we manage products.

A feature tracking system needs to be able to support a hierarchy of features with infinite depth. We need to be able to track the status of each feature and subfeature of feature to know when it was released, the status of testing, documentation, coding, and etc.

In addition to our feature tracking system, we need a separate list of tasks related to the feature. Tasks are all the actions that need to be performed to move the feature from concept to realization. The product manager should manage the features, the development team manages their tasks. Features are aspects of the software that you always want to keep track of like, “This is our reporting feature that saves to PDF or prints. We added it in version 7.0 of the software. It was coded by Joe and Jeff and was tested by Susan on 2/27/2009.” Tasks, are the list of actions used to implement the feature and you usually can discard the list of tasks used to move the feature from idea to implementation. The tasks for implementing a feature may include items like:

  1. Add columns to the database table
  2. Modify these 3 stored procedures
  3. Verify that the SQL Server stored procedure converted to Oracle correctly
  4. Confirm the sort order is correct
  5.  Write the unit tests for the feature
  6. Write the code for the feature
  7. Write the programmer documentation for the feature
  8. Write the user documentation for the feature
  9. Test the feature

Notice that Projects and Tasks are similar.  Both have start dates and end dates.  Also notice that Products and Features are similar.  They do not have completion dates. 

A lot of the challenge in developing good software is based on your ability to manage your to do list effectively.  One step in achieving that goal is to maintain a clear separation between tasks and features.  You may need two separate systems to track each well; but ideally you can find some software that tracks both.

Posted in Coding, Project Management | Leave a Comment »

Agile is simply the course requiring the least amount of work

Posted by robkraft on January 6, 2011

I spent time today planning the features to include in our next four releases over the next two years.  A small part of me kept telling myself that I was not being agile.  I did this planning because I am using the plan to determine how to design some code for the next release.  Am I right to believe that the capital “A” Agile purists would tell me I am doing something wrong?

My response to the purists is that I don’t care if I am an Agile purist or not, and I don’t care about Agile at all.  I just want to produce the best software I can, and I will adhere to Agile when that seems to be best, but I will deviate from Agile when the pure Agile approach does not seem to be best.

For our next release, I need to design a specific pattern for hundreds business objects to follow.  We will update our code generator to create all the business objects.  The objects will be read-only versions in the first release, then editable objects in the second release, then objects that support asychronous methods in the third release.  I had considered having all three versions inherit code from a single base class, but upon realizing that we would eliminate the read-only objects in the fourth release, I am chosing not to use this base class idea.

In short, I let an uncertain future determine my present design.  But I argue that doing so is the correct thing to do, and that it is neither Agile, or not Agile.  I must chose a design to implement, and the more information I have about the future the more likely I am to make a decision that minimizes the amount of work to be done.  By looking into the future I am choosing a design that will actually save us one month of work in the first release, and will provide residual savings in subsequent releases.  If I looked into the future and chose a design that ADDED months to the first release and provided no additional value my actions would not be Agile.

My conclusion is that you are being Agile when you select the course of action that requires the least work in the early stages, but that over the long term an Agile approach runs the risk of being less efficient.

Posted in Code Design, Project Management | Leave a Comment »

How Agile is your team compared to others?

Posted by robkraft on December 28, 2010

Find out at

Posted in Project Management | Leave a Comment »

Scrum is not agile!

Posted by robkraft on October 25, 2010

Scrum is not an agile process.  I am saying this to get your attention, but I am also saying it because there is some truth in the statement.  Our development team has been striving for agility for years now.  When I use the term striving, I am not implying struggling, rather I am implying that I don’t think “Agile” is something to be obtained.  It is not an end goal, it is a behavior.  Once you reach a point where your development processes are finalized and no longer changing, you are no longer agile.  So if you want to remain agile, you have to keep looking for ways to improve your processes.  You will never obtain that end state of how to develop software the best way.

I know.  I know.  Scrum includes retrospectives and through the retrospectives you identify process improvements to make.  Therefore Scrum remains agile.  That is true, at least for those few (apparently few) teams that make use of the retrospective.  I think many teams don’t feel they have time for the retrospective and don’t believe they will have much value.  Many scrum masters and former project managers get tired of tinkering with the processes and just want to know the patterns to be followed over and over.  There is certainly benefit to habits and in knowing what to expect.  But it appears that a lot of teams leave out the retrospective and therefore are probably leaving out the agility.

Even worse than the teams that skip the retrospectives may be the teams that seek adherence to scrum above all else.  You know these guys from their posts on the blogs and message boards.  They have taken scrum to heart and will not suffer anyone to criticize scrum in any way.  Unfortunately it may be these people that are the least agile because they are not open to any process that is not part of scrum.  I understand how this occurs.  When a waterfall development shop seeks to improve their software development processes, they come to believe that scrum will provide such success, and they try fervently to adopt scrum.  The danger for some is that they forget the ultimate goal is to write better software, not to adhere to scrum; and if the best software can be developed without 100% adherence to scrum principles, then you should ignore those principles that don’t work for you.  Remember, the goal is to write better software.  So skip those daily standup meetings, or change their content, or allow the scrum master to also be a developer or dba, or break any of the other rules of scrum if they are not working for you.  Remember, an agile team is willing to try new things to find what works best.  You are in a constant state of discovery.  If someone tells you that you are not agile and not scrum because you aren’t doing a daily standup, just tell them that you don’t care because instead, you write great software.

Posted in Project Management | Leave a Comment »

My plane is not flying in a straight line

Posted by robkraft on October 22, 2010

I see a lot of tension during software development between getting a feature 100% right and getting something out the door.  The merits for “doing it right” should be obvious, but some developers fail to see the merits of “not 100% right, but something we can release”.  This problem is analogous to flying a small plane around the world.  One could argue that you should take the most direct and shortest route. However, if you choose to do so, you may find that your plane has run out of fuel before you complete your journey.  To successfully navigate the globe, you must take a course that is “less than optimal” because you need to make stops at fueling stations along the way.  Your plane expends extra fuel because it deviates from the straight line to get to the fueling station, and it expends more extra fuel because it must alter course after fueling to get back to the optimal path.  In software development, sales of your software may be your fuel, or customer satisfaction may be your fuel.  Either way, there are benefits to releasing software that still has known bugs.

This scenario, like many software development scenarios, depends greatly on context.  If the software maintains a life support system and is producing errors, it may be unacceptable to ship the software.  If the error is that a caption is misspelled, then it may be acceptable.  In my own experience, the owner of the software ultimately makes such decisions.  It is the software owner that should decide if the software should be released on the promised date with bugs, or delayed to a future date in which hopefully those bugs will be fixed.  For many deadlines our software team has elected to spend our last week adding a new feature instead of fixing all the bugs in other features.  This is not to say that this decision is best for your environment, but for us it was more important to get the features out and get feedback on them than to have them 100% polished.  Some features we release are not adopted or clients desire significant changes to them to be satisfied.  In those cases, we saved a lot of time by sending out what we had instead of spending additional weeks or months to polish to perfection a feature that would not be used.

Posted in Code Design, Project Management | Leave a Comment »

Software is not art!

Posted by robkraft on May 12, 2010

Software is not a piece of art, produced in a way that the artist feels is perfection. Software developers should think of software as providing solutions to users that users desire primarily for increasing their productivity. So, instead of spending three days to figure out how to override the default colors on windows controls so that they all match, instead spend that three days adding a logging framework, or an export to excel. Let the customer determine which features are more important to them. You will learn that they often prefer to keep bugs that they can tolerate if provides you time to add a new feature they really want.

Posted in Code Design, Project Management | Leave a Comment »

It’s not easy to prioritize the work to be done

Posted by robkraft on May 12, 2010

It is difficult to provide a formula for prioritizing the work to be done. On the surface, it may seem that we should, “Do what is most valuable to the users”, but that is often not the formula used and for good reason. Sometimes we must do a task for political reasons, because the boss demands it, or because we need to change the way this code works to make a particular person happy so that we can work with him better on other tasks. Sometimes it may be done because a client keeps asking about this one change.

Besides the political, you may choose to have a junior developer work on a feature even though it is not the most important thing he could work on. It could teach the junior developer a valuable skill. We want him to get better at Silverlight, and he could probably add this Silverlight feature, so we will have him add this to increase his skills. In this case, we are sacrificing the best feature now in order to make him a better developer so that as a team we have better options in the future.

A third reason for ignoring the next most important feature is that we include some of the lower priority features in with a high priority feature because the high and low priority features are all part of the same code base. Developers usually say, “While we are in that block of code, we might as well add these features…” This is often beneficial because the developer does not need to repeat the time invested understanding that section of code, and the overall testing time of the features may be reduced.

Are there other reasons that we work on features other than what is most valuable to the end users?

Posted in Project Management | Tagged: | Leave a Comment »

More reasons that software estimates are inaccurate

Posted by robkraft on May 11, 2010

One source of inaccurate software development estimates is the residual impact of a new feature. On a recent project we decided that we wanted to persist the user’s column width customizations in the grid of our Silverlight application. We estimated that we could complete this in just two hours, so we did so. However, after we implemented the feature we realized related issues that needed to be addressed and thus all took additional time. Some of these issues were:
• Will the customizations persist if we release a new version of our code?
• What happens when a user resizes the entire form and grid? Is that the behavior we want?
• What happens with a grid designer adds or removes columns from a grid that a user has saved customized column widths for?
• Should we have tied the customizations to the grid id or to the form id the grid was displayed on?

Residual issues and questions like these often show up during the development and testing of a new feature and are not accounted for in the original estimate. Some of these can be resolved in less than ten minutes, but others may take much longer.

What does this mean to a development team? Just that several people should generally be involved in the decision to implement new features and that a few extra minutes should be spent up front to identify as many issues as possible if you desire the implementation time required to be close to what you expected.

Posted in Estimating | Leave a Comment »

Analogy – Estimating Software development is like estimating drive times

Posted by robkraft on February 12, 2010

Estimating a software development project is a little like estimating driving time.  If you are estimating something you do over and over, like your drive to and from work, then you can provide estimates that are very accurate.  However, there is always a chance for unexpected traffic jams and bad weather that could unexpectedly make your estimate grossly inaccurate.
When estimating a trip that you have not taken before, the accuracy of the estimate decreases with your knowledge of the possible paths and the accuracy also decreases with longer distance.  Is it not the same with software?  Our estimates become less accurate when there are more things we need to do that we are not familiar with, and as the scope of the project increases.

Posted in Estimating | Leave a Comment »