Rob Kraft's Software Development Blog

Software Development Insights

Archive for the ‘Project Management’ Category

Agile Baby Steps: A Parable To Help You Get Started

Posted by robkraft on March 20, 2016

We often hesitate to take the action that shows we are committed to doing something new. We read about it, analyze it, and try to understand it; but real learning requires that we go beyond reading. We must DO. The goal of this article is to get you to take action toward becoming Agile, without understanding or adopting all of the habits of an Agile development team. I am asking you to try out some new processes in your software development life cycle, without considering whether or not you are doing Agile development.

Side bar: Your ability to implement an Agile technique depends upon the process by which your software is implemented. An Agile development technique that works for one process may not work for another, so be cautious of Agile recommendations that state you must do something specific or you will fail at being Agile. Your goal is not to be “Agile” by anyone’s definition. Your goal is to write better software. 

  • Some software developers write code then send it to a quality assurance environment who then push it into production;
  • Some software developers write code for embedded systems where all the software must be completed before it is written to a chip;
  • Some software developers check in code that that runs through automated tests and gets published to a public web site without further human action;
  • And some software developers follow other models for implementation.

The process by which you take code from development into its final environment greatly affects which agile techniques will work for you.

The Parable Begins

Let me share with you a parable of two teams, each tasked with developing the same software, but each using a different methodology.

Team Agile used an agile methodology, and team waterfall used a waterfall method. Both teams were asked to build a web application to allow users to manage data in an existing client-server application.

Team Agile met with the end users, usually known as the product owners in agile, and learned the high level requirements and features desired for the entire application. Because they did not gather detailed requirements, they spent only eight hours on this task.

Side bar: Delaying the gathering of detailed requirements often adds value in several ways:

  1. You don’t spend time gathering and documenting detail requirements for features that later get cancelled or excluded from the project.  If the team spends ten hours detailing the requirements of a feature that management decides not to implement a month later, then the team wasted ten hours. Eliminating waste is the major focus of Lean and Kanban styles of Agile development.

  2. Another reason to delay gathering detailed requirements is that every team member will be smarter in the future than they are today.  Each will know more about the application and may learn that ideas considered early in development are not as effective as new ideas learned since. Perhaps a developer read about a new programming technique or tool; or perhaps the product owner learned about a better way to design a user interface. You can implement these new ideas and techniques even if you documented detail requirements for the old techniques, but that means the time spent gathering and documenting requirements for doing it the old way was wasted time.

Prioritization

Team Agile also asked the product owners which features were most important. The product owners initially said all of the features were necessary and important, but after more discussion the product owners provided this prioritized list of features:

  1. Users need to be able to log in
  2. To view data
  3. To edit data
  4. To add data
  5. To delete data

Prioritizing features is an important, and necessary feature of agile development, as we shall see later. If you do not prioritize the features you are going to work on, you will probably not receive the benefits that agile development can provide.

Meanwhile, in a parallel universe, the Team Waterfall also met with the end users to gather requirements. They spent much more than eight hours on this task because they needed detailed requirements for all the features. They planned for little interaction with the product owner after this meeting until the product was finished. Team Waterfall spent sixty-four hours on requirements.

The Login Feature – Deploy Early

Team Agile next then did some design for the project. They thought about all of the requirements they had learned about, but they only did a detailed design for the first feature they worked on; and that feature was the ability to log in. They spent four hours on the design of this feature.

Then Team Agile coded the login feature. The coding took eight hours. Next, Team Agile turned the application over to the Quality Assurance (QA) team. Even though the entire application was not completed the QA team found a few problems with the login feature. Team Agile fixed those problems, and the QA team could find no more defects.

Side bar: Agile development does not magically prevent programmers from creating bugs, but it does make developers aware of the bugs sooner, so they can fix them while the code is still fresh in their minds and before some errors might get propagated into more of the code.

Team Agile implemented the application in production. Now, this seemed a little silly to some people, because the application did not do anything other than let a user login; but it turned out to be very valuable. They discovered that the software did not work in production. The production environment had an older version of the web server that lacked some features the application depended on. Team Agile met with IT to discuss the problem and decide if the web app should be re-written, or if the production web server could be upgraded to a newer version. They decided the web server could be upgraded, but it did require two weeks for this to be completed.

Agile Manifesto Principle #1: -“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”

Side bar: Not all software can be deployed in small pieces, such as software embedded on chips or shrink-wrapped software. But some software, like the software in this parable, can be deployed in pieces. By taking the software as far as possible along the path of implementation you may discover problems. It is always best to know about problems sooner so they can be accounted for in the project schedule and possibly used to correct the product requirements, design, and code. A product developed using a waterfall method has a higher risk of failing to discover some problems until all the code is completed and thus incurs significantly higher costs to correct the problem.

Side bar: Agile methodologies reduce the risk of unknown and unexpected problems by revealing them sooner.

The View Feature

While Team Agile waited for the new web server to be implemented in production, they proceeded to work on the second feature, “Allow users to view data”.   They met with the users to get more detailed requirements about how they would like to view the data. They spent eight hours on this task. Team Agile then created a design, including some mockups and reviewed the mockups with the product owners. After this sixteen hours of work the developers were ready to begin coding.

I have not forgotten about Team Waterfall. During all this time that Team Agile did the activities above, Team Waterfall has been gathering requirements. Team Waterfall is now ready to design the application, and they will spend about forty four hours in design, which is a little less than the total amount of time Team Agile will spend on design. In this parable, Team Waterfall benefitted by designing the entire application all at once because it was all fresh in their minds as they did it. Team Agile, on the other hand, did parts of the design spread out of several months, and had to spend part of that time recalling why some decisions were made. However, the advantage still goes to Team Agile, as we shall see, because Team Waterfall will discover that much of their time spent in design was wasted.

Team Waterfall completed their design then started coding. They chose to code the view and edit features first, and at the same time because they believed them to be the most interesting and fun part of the code to write. For both Team Agile and Team Waterfall, the coding phase(s) of the application take the longest; around three hundred hours. At the same time that Team Waterfall is working on the total application design, Team Agile begins coding their second feature, “Viewing Data”.

Communication With Product Owner

For both teams, the time spent coding is the same for all features except for “Viewing Data”. Team Agile spent one hundred and twenty hours coding this feature, but Team Waterfall is going to spend one hundred and sixty hours coding this same feature for the following reasons.

  • In the first week, a developer attempted to implement a list box on a form as had been requested in the requirements. But the developer found that this data would be difficult to display given the list box features. He realized he could easily do this with a grid though.  So the developer brought this up with the product owner during the daily status meeting, and the product owner said he didn’t care if it was a list box or grid, he barely understands the difference between the two, and he would just prefer to defer that decision to the developer. So the developer used a grid instead of a list box and saved an estimated forty hours of work that would have been needed if he had tried to make the feature work using a list box.

Agile Manifesto Principle #4 – “Business people and developers must work together daily throughout the project.”

  • In the second week, another developer was working on a feature to let users pick their own colors for the forms. The requirement called for a text box in which the user could type a hexadecimal value representing the color, but the developer had recently learned about a component that could just as easily provide a color picker to make it much easier for the end user. Instead of adhering to the requirements the developer showed the product owner liaison an example of the color picker and asked if this change would be acceptable and the product owner liaison loved the idea, so it was implemented.

Agile Manifesto Principle #6 – “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”

Side bar: Once again, the ability for frequent interaction between the developers and the end users throughout development facilitates many improvements. Also, developers are often more aware of the capabilities of technology than the end users and can make suggestions for improving the application based on that knowledge. When the discussion for detailed requirements can be delayed and the developer writing the code can be involved, there is a greater chance for a better solution.

Side bar: A good technique for software development, and for many decisions in life, is that it is best to commit to a decision as late as possible because your knowledge later in the life cycle is greater than it will be earlier in the cycle.

Reports Feature – New Requirements

During Team Agile’s development of the “View Data” feature, the product owner realized they had omitted the reports feature from the project. The reports are used by every user and are much more important than the ability to delete, add, or even edit data. The product owner and the developers had a meeting about the omission and decided that the developers would add the report feature next, after they finished View feature.

Agile Manifesto Principle #2 – “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.” The ability to accept new requirements and to change the priorities of features developed is one of the most noticeable and valuable aspects of agile development.

The development team finished the view feature and easily deployed it into production. The product owners started using the application, even though all of the features were not available.

Agile Manifesto Principle #3 – “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. “

Deploying the view feature provided several benefits:

  • The company could begin deriving value from the application. In financial terms, the Return On Investment (ROI) starts occurring sooner in Agile projects than in Waterfall projects.
  • The users became more productive because the web application was easier and faster to use than the client server application. It was also easier for the IT staff to make it available to more users.
  • The users found bugs in the application. Finding some of these bugs may prevent similar bugs from being developed in the remainder of the application. For example:
    • The users found that there were no accessibility keys. So the development team planned to add these to the view screens, and were proactive about adding this feature in future development.
    • The users became more productive because the web application was easier and faster to use than the client server application. It was also easier for the IT staff to make it available to more users.
    • Twenty percent of the users found that some features did not work on the particular browser they used, which was different than the browser used by the developers and most of QA.
    • A few bugs were found causing incorrect data to be displayed.
  • Side bar: Teams often desire to fix bugs right away, but in an Agile environment, especially one with short one-week or two-week iterations, this can be counterproductive. It is generally best to let the team complete what they started in an iteration, then make the fixes to the bugs a top priority for the next iteration.

Waterfall Team Progress

Let’s check in on Team Waterfall. At the same time Team Agile is coding and deploying the “View Data” feature, Team Waterfall chose to code the “View Data” and “Edit Data” features, and they are still in the process of doing this. They have nothing yet to show to the product owners, so let’s turn back to Team Agile, because they have some visible progress that we can check on.

Agile Manifesto Principle #7 – “Working software is the primary measure of progress.”

Team Agile finished the “View Data” feature, and started to develop the “Reports” feature next. The requirements and design only took sixteen hours, and by this time the reports of bugs in the “View Data” feature were coming in. However, the team felt they could and should complete the “Reports” feature before working on the bugs so that they did not incur the cost of switching back and forth between tasks. The product owners accepted this decision because the development iterations were short, and the development team said they could start fixing the bugs next week.

After finishing the “Reports” feature and deploying it to production, the team spent a week fixing the bugs in the “View Data” feature. Some of the bugs had made some views unusable, and other bugs, such as accessibility and support for other browsers, would affect how they developed all subsequent features.

Side bar: Agile development does not magically eliminate bugs, nor does it prevent errors in requirements, design, and communication. But Agile development does reveal most bugs sooner so they can be fixed more quickly and cost less to correct than they would in waterfall development.

Team Waterfall is still coding the “Edit Data” feature at this point in time. It took them longer to code the “View Data” feature than it took Team Agile because Team Waterfall made the list box work as documented in the requirements rather than go back and talk to the product owners about using a grid instead. Team Waterfall also spent time explaining to the product owner that they could not add the “Reports” feature to the product because they had already gathered all of the requirements and done the design and they would need to redo some of that for a new feature. Ultimately, the product owner agreed to increase the product budget and provide proper paperwork for a “Change Request” to the requirements of the system. Team Waterfall then spent eighteen hours gathering the requirements and changing their design, which included changing the design of some database tables they had not started coding against yet. Since Team Waterfall still has nothing to show, we will go back and see what is happening with Team Agile.

More New Feature Requests

Team Agile has started the requirements and design of the “Edit” feature. During development of the edit feature, the product owner realized they had omitted filtering and sorting abilities in the view feature and that filtering and sorting was really necessary to make the views more valuable. Team Agile decided they would add sorting and filtering to views right after they completed the editing feature.

The Cancellation of the Project

But in the next week a new project came in and the developers were asked to suspend this project and work on the new project. The new project was very important, of course, and would probably take the team a year to complete. Team Agile was given one week to wrap up this project and begin work on the new project. For Team Agile, the editing feature was almost done, but the date and time pickers only worked on one browser and the developers estimated it would take them three to five days to get new date and time pickers working on all browsers. Team Agile had to choose between these options:

  1. Add filtering and sorting to views and not release the edit feature
  2. Finish the edit feature so the date picker worked on all browsers and users would not have to type in dates, but not add filtering and sorting to views
  3. Add filtering and sorting to views and release the edit feature without a date picker, requiring users to type in the date.

Team Agile desired to complete the edit feature by making the date picker work because they did not want to provide the end users with a subpar, low quality product; and they thought it would make the developers look bad if the app did not have the simple date pickers. But the product owner said that the filtering and sorting of views was most valuable, and that they would take the editing feature even without the date pickers because the ability to edit data from the web application would provide some value to users even if the feature was not finished perfectly.

Side bar: Agile development often gives the product owner insight into the product development processes and decisions. This is almost always a benefit to the business because the product owner can help guide the product outcome to a solution that provides the best ROI for the business. However it can, occasionally, upset some developers when they feel they are asked to cut quality to get the job done. The developers may feel it will reflect poorly on them. It is up to the management teams to convey to the end user the decisions made in this situation were those of management, and not the developers.       Waterfall teams rarely have this dilemma because the product owner is unaware of all the decisions made.

Speaking of waterfall teams, as in the side note, what is going on with Team Waterfall now that this new project has arrived and they must work on the new project instead. Well, one benefit for Team Waterfall is that they can start on the new project right away instead of spending a week trying to wrap up the old project because there is no way Team Waterfall can deliver anything within one week on the old project; they never even started the Login feature of the application. The obvious enormous downside for Team Waterfall is that they will deliver nothing to the end users, and all the time spent on the application can now be considered waste. That is not the case for Team Agile. Even though the project was terminated early, the agile team delivered something of value that could be further enhanced in the future.

Agile Manifesto Principle #10 – “Simplicity–the art of maximizing the amount of work not done–is essential.”

I provide two summaries to this parable. The first, is a summary specific to the tale, and the second is a summary of general conclusions to be made about agile development.

Specific Summary

  • Team Agile delivered some business value, but all the time spent by Team Waterfall was a waste.
  • Team Agile reduced the development time of some features by frequent interaction with end users and by being open to changing the requirements.
  • Team Agile provided a better way for end users to choose their colors than team waterfall because the UI decision was not made until the feature was developed and in that time the developer had learned of a new component.
  • Team Agile accommodated the “Report” feature because they had a prioritized backlog and could easily queue it up to work on next. Team Waterfall did not prioritize their work, so any new development would probably just be added at the end. Team Waterfall would need to alter their existing requirements and design.
  • Team Waterfall never learned that their app would not work in production due to the older web server. It is probable that the team would be rushing to deliver this product by a deadline, only to discover right at the end that additional time would be required. It could have been even worse if IT was unable to upgrade the web server and the development team had to go back and change code to make the application work on an older web server.

General Summary

  • Agile teams often waste less time than waterfall teams.
  • Frequent interaction with end users can produce a better product with less waste. This is not exclusive to agile development, but it is more common to agile development than to waterfall.
  • The willingness to accept flexible requirements can produce a better product with less waste. This is more difficult to do when all requirements have been gathered up front and have been included in a design.
  • Delaying requirement and design details can lead to better decisions at the time the decision needs to be made.
  • Agile teams accept new requests easily by adding them in the backlog. They do not have a lot of time invested in any features in the backlog because they wait and do the detailed requirements and design for them when they are about to code them.

If you want to become more Agile today:

  • Create a prioritized backlog
  • Select features from the backlog that you will complete during your next iteration. A good iteration length is two weeks.
  • Make sure that you don’t just code the features, but that you include testing and deployment, if possible, to be done within your iteration.
  • Do not work on several things at the same time. Complete each feature as much as possible.
  • Finish what you start each iteration. Do not add interrupt what you started in an iteration by working on something new that came in to the backlog. Wait until the next iteration to start it.
    • Sometimes, something very high priority will come in that must be completed right away. Agile developers understand and accept this.
Advertisements

Posted in CodeProject, Process, Project Management, Uncategorized | Leave a Comment »

Use Fuzzy Hours for Your Software Task Time Estimates

Posted by robkraft on June 14, 2014

Like many software development shops, we need to provide estimates of the time required to fix each bug and add each new feature.  The primary reason for the estimates is to set expectations for when tasks will be completed and to prioritize what is to be worked on.

As an agile shop, we have tried a few scales for estimating such as:

tiny, small, medium, and large and also the Fibonacci sequence:    1, 2, 3, 5, 8

but the one we have been using for years that we like best is fuzzy hours.

We use the symbols 1,2,3, and 4 where:

  • 1 means 0 to 2 hours
  • 2 means 1 to 8 hours
  • 3 means 4 to 40 hours
  • 4 means more than 30 hours

Notice that our ranges overlap and that is what makes them fuzzy.  When an estimator feels an estimate is in a fuzzy zone it is up the estimator to pick one zone or the other based on their gut feeling.

We have also learned that the velocity for all items sized 1 and 2 are the same, and items with a size 3 take only slightly longer to reach a completed state (development, testing, quality assurance, and documentation all complete).  Items with a size of 4 take longer, but only about twice as long on average as a 3.

Posted in Estimating, Process | Leave a Comment »

Software Project Management Challenge #3

Posted by robkraft on January 15, 2013

The software we write is used by many clients. Each client uses a different set of features. Clients can’t enable features they have not paid for, but we discovered that clients can change some of the configuration options for features they have not enabled, and configuring some options for disabled features will cause bugs to occur. Fixing this problem would require days of refactoring, coding, and testing. It is unlikely any clients will ever encounter the bug, and the impact of the bug is minimal.

  • Should we issue a service pack right away that fixes this problem?
  • Should we fix it in our upcoming release?
  • Should we fix it in a future release?
  • Should we never fix the problem?

This challenge is typical of the decisions that need to be made every day in software development. I don’t believe there is a correct or best answer to this scenario.

  • The policy in some software development shops is to fix every bug as soon as it is discovered, but is that the best use of developer time?
  • The policy in some software development shops is to delete the bug from the bug tracking system if you don’t plan to fix it soon because you will probably never get to it. Is it more valuable to keep a record of the bug in the backlog in case it comes up again or is it more valuable to delete it from the backlog so that no one wastes time re-evaluating if it should be worked on?

There are many factors that go into making this decision and I’m sure I cannot think of all of them. Can you?

Posted in Project Management | 1 Comment »

Software Project Management Challenge #2

Posted by robkraft on November 12, 2012

We have a developer, I will call him Rob, who writes many utility programs and rarely works on the main product with the other developers. One of the utility programs needs a new feature to allow our customers to see, modify, remove, and add items to a list. Rob shows all the data in a grid, and needs to allow customers to add items to the grid. This could be done in two hours by placing an add button on the form. But Rob wants to use the add feature built into the databound grid.

        

We all agree that the utility will look better if the add is done in the grid instead of a using a button, but we also estimate five days instead of two hours to get it to work. This means Rob will not be able to work on a few other features for the release. However, Rob is likely to hold a grudge for years if not allowed to write the code using databinding to get the aesthetic look he desires.

Should we allow Rob to take the extra time to write the code that will be more pleasing to the customers, and to Rob; or should we require Rob to write the code more simply so that additional customer requested features can be included? If we choose the better user interface, we must leave some features out of the release.

If we choose more features, we risk questions from our customers like, “Why didn’t you just allow us to do the add in the grid”, and we also risk displeasing Rob.
Should our decision favor the needs and desires of our customers, or the needs and desires of our developers?

Posted in Coding, Project Management | 1 Comment »

Software Project Management Challenge #1

Posted by robkraft on October 30, 2012

The software programmer has added a feature to the program as requested but the feature contains a minor flaw.  The programmer has spent four hours trying to eliminate the flaw with no success.  As shown in the images, the flaw is a visual flaw.  When the screen is resized to a smaller size, one of the input fields vanishes.  But any subsequent resize causes the missing field to re-appear.

 

Should the programmer continue to fix the flaw?  None of the programmers has any ideas for how to fix the flaw, they have already researched and tried everything they can think of.  No time estimate can be made for the fix; it might take 2 hours or it might be impossible to fix.

Your software has 5,000 users, but you estimate this feature will be used about once per day by 10 of those users on average, and if those users don’t resize the screen they won’t notice a problem.

  1. Do you have the programmer continue to work on the flaw for 8 hours and then re-assess the issue.
  2. Do you have the programmer spend 40 hours redeveloping the feature completely in a different way that hopefully will have no problems.
  3. Do you remove the feature from the code hoping to try to implement it again in a future iteration?
  4. Do you create a new ticket in the bug tracking system to address the problem in the future, or do you leave it unrecorded and hope it is never reported.
  5. If you create a new ticket in the bug tracking system, do you include the bug in the list of known bugs in the application?
  6. Do you tell your quality assurance team to ignore the bug; to not report it as a bug.

This challenge is typical of the decisions that need to be made every day in software development.  I don’t believe there is a correct or best answer to this scenario.  Perhaps you have a junior programmer doing the work and you feel it would be good for him to spend a few days trying to resolve the problem.  Or, perhaps the project is behind schedule and you have several more valuable features to complete so you decide to leave this one as is.  Or perhaps you software has been critiqued severely lately for releasing code with bugs so you decide it best to take this feature out to reduce further stains on your reputation.  There are many factors that go into making this decision and I’m sure I cannot think of all of them.  Can you?

Posted in Project Management | 1 Comment »

There are no I.T. Projects, only Business Projects

Posted by robkraft on October 28, 2012

Businesses often turn to software and computers to solve problems and gain a competitive edge.  When this occurs, both the business analysts and the I.T. staff have a solution in mind that requires computing technology and software.  Sometimes though, non-technical solutions solve problems better and with far less expense.  One current classic example is the use of a white board to track the project of work being done during a software development iteration.  That white board does not need to be electronic, so don’t spend weeks or months creating the white board software especially when all interested parties are located in the same office or room.

Keep in mind these three principles:

  • Can we try out the new process or idea manually, with minimal investment, without spending the time to develop the idea using software.  If we feel the process still requires automation after a few months, can we at least learn some of the requirements from performing the process manually in the first few months.
  • Is the cost of developing the software the best use of our scarce resources?  If purchasing a software solution, is the cost of the purchase worth the investment?  Many companies spend a lot of resources developing software that is not part of their core business.  Doing so is depriving your business of the resources it could be using to better the products that really drive the business.
  • Just because your software developers are busy does not mean you are making progress.  I once learned of a doctor that traveled an hour between two hospitals.  He saw four patients a day because he spent four hours traveling back and forth.  The doctor was constantly busy, but the doctor was not near as productive as he could have been.  Once the doctor changed the schedule of the patients to meet all the patients at one hospital in the morning, and all the patients at the other hospital in the afternoon, the doctor was able to see twice as many patients each day.

Posted in Process, Project Management | Leave a Comment »

Use Root Cause Analysis for Defect Prevention in your Software Development Process

Posted by robkraft on February 5, 2012

Recently I decided to review all the bugs we fixed in our last release to determine if they originated from a few common causes.  In software development, there is not a lot of data that can be mined that may provide insight into actions to take to improve software development, but I thought this might be one.  We fixed about 40 bugs in the last release, and I can tell you right now that my analysis has not lead to any significant changes in the way we develop software.  This is not because we didn’t find areas that could benefit from improvement, it is just because, in our case, attempting to make improvements to reduce the source of the bugs is not currently more valuable than other tasks we can be working on.

Of the bugs we found, I considering them to be “coding flaws”,  “configuration flaws”, “design flaws”, “process flaws”, or “requirements flaws”.  I realize that my technique is crude and I have very little data to draw definite conclusions from, but this is an exercise that anyone on a project team can perform if you are tracking the defects fixed in a release.  You may find patterns that help you identify aspects of software development most in need of improvement.  An excellent paper based on a lot of software development data at NASA is online here: http://www.hpl.hp.com/hpjournal/96aug/aug96a2.pdf.  The goal of the study in the paper, and my goal is well, was to use this “root cause analysis” to determine ways to prevent and reduce defects in the software.  Given that excellent article provides much more detail than I enter into here, I recommend that you read it if you are really interested in improving your development processes through root cause analysis of your bugs.

I will add here, a list of reasons that I came up with for the sources of bugs in our code:

18% – Coding Flaws.  The programmer did not think the issue was a bug, or the programmer did not test the issue thoroughly, or the programmer felt it was insignificant and lacked the time to address the problem.

39% – Coding Flaws.  The programmer should have noticed the problem.  But perhaps senior developers or business analysts should have provided a junior developer more training and input so that the junior developer would have recognized this as a problem.

3% – Coding Flaws.  The bug is a bug in 3rd party software we use (in this case Microsoft), that we need to wait for them to fix, or rewrite the feature.

5% – Coding Flaws.  The programmer should have just provided an error message to the user that is easier to understand.  Perhaps the message provided should always be determined by a business analyst.

5% – Coding Flaws.  A known bug was released.  The bug had minor impact and the cost to fixing it was high, as was the cost of delaying the release.

8% – Configuration Flaws.  We use code generation for much of our code.  The business analysts made mistakes that led to improperly generated code.

5% – Design Flaws.  The design did not allow for a feature to work as it needed to in some situations.

8% – Process Flaws.  We don’t test 100% of the User Interface possibilities in our application because the time required makes it impractical.  However, such testing is unnecessary for most of the code as long as we follow our processes for development.  In a few cases, we failed to follow the correct processes.

3% – Requirements Flaws.  The developer was not aware that the feature was desired.

3% – Requirements Flaws.  The requirements provided to the developer were incorrect.

3% – Requirements Flaws.  We removed a feature from the software that we thought was not being used, but it was and we had to re-add it.

We also improved performance in the last release.  Another way to phrase that is that we fixed performance problems.  It is difficult to decide if improving performance is fixing a bug or not when it doesn’t violate a clear service level agreement.  A code change is not always objectively a bug fix or an enhancement.  If the client believes it was in the original specification, the client will say the missing feature is a bug; but if the developer thinks the feature was not in the specification, then the developer will consider the addition of it in the next release to be an enhancement.  Just part of the joys of software development.

Posted in Code Design, CodeProject, Process, Project Management | 10 Comments »

The Next Generation of User Group Meetings

Posted by robkraft on December 2, 2011

In the Kansas City metro I’ve noticed an increase in the number of computer user groups forming to meet and discuss and learn about software technologies.  Some of these groups have exploded on the scene with an average attendance of more than 30 people per meeting, which outdoes groups that have been existing more than a decade with less than 10 people per meeting.

But I think it is time to try to do more.  I think we can do a better job.  I think the goal is to increase the knowledge of technologists about all the things they are interested in; and I’ve noticed that some of the most popular meeting topics are about “other things”.  For example, training on Ruby at the .Net meeting produces a large crowd; and training on IIS at the Java meeting produces a large crowd.  Why is that?  I believe it is because most developers recognize the need to have at least some knowledge of the tools they don’t regularly use.  By raising our own awareness of other tools and techniques, we are open to more possible ways to solve problems.  More importantly, after we have learned the basics and some pros and cons of a new tool or language, we are less intimidated by that tool or language and more open to consider using it in future projects.

What does this all mean for user groups?  I believe that we should continue to have the “Special Interest Groups” to focus on the arcane and specific features of the group’s named technology.  But I believe we need a general interest group that presents tools and technologies at a high-level (introductory level) that can be marketed to the entire community of developers in the metro.

How do we go about this?

  1. We need to find a venue to host these meetings.  My hope is that we can draw 50 to 200 people at each meeting.  Therefore, we would want a venue that can accommodate such a crowd.
  2. We need to identify topics of presentations that can be presented as introductory material to this large audience.
  3. We need to find good presenters that are enthusiastic about presenting and answering questions on these topics.  In addition, the      presents will probably, but not necessarily, need to create the presentation.
  4.  We need to get the word out to all IT people in the KC Metro about the event.  And I want to jump on my soap box here and say that the goal is not to get as many bodies as possible at the event; the goal is to make everyone in the KC Metro that might be interested in this topic aware of the opportunity to learn.
  5. We need coordinators to bring all these elements together at the same place and time.
  6. Optionally, we could obtain sponsors to help pay venue costs if any, and to provide food, drinks and prizes; but I don’t believe that food, drinks, or prizes are necessary to draw the crowd.
  1. Now I am not sure what venues can hold this many people.  I believe that JCCC could do it, and probably would be open to it; but their business needs usually come first.  Red Nova Labs and VML both seem to have large venues, but I don’t know if they are large enough.  Can you suggest other venues?
  2. The list of potential topics is long.  I will start a list with these items: TDD, Agile, Kanban, Starting in Ruby, Perl, JavaScript, Jquery, HTML5, CSS3, SQL, Unit tests, Inversion of Control, Asp.Net, MVC, MVVM, SQL Injection and XSS, Starting in .Net, Starting in Java.
  3. The list of good presenters is also long.  In fact, the current local user groups, those that I collectively refer to as Special Interest      Groups, could serve as the training grounds for finding presenters.  If you know someone that gave a great presentation at a local user group, then recommend that person and their presentation for the new general interest group.  Also we need to hear from presenters      about topics they would like to present.
  4. We already know several ways to get the word out.  www.KansasCityUsergroups.com, and www.kcitp.com and linkedIn.  We would, of course, set up a simple web site with info about the upcoming event.  We could contact all the local groups and have them announce the meeting.  We might also spread the word by creating a meetup for the event.  We could start a twitter hash tag as well.
  5. We need people to do these things.  I believe that if we can get 5 to 10 people behind this to do the work, it will be enough to make it happen and those 5 to 10 won’t get burned out.  Personally, I would like to be one of the marketers to spread the message about the upcoming meetings, and I hope Mike Gelphman would work with me.  I would leave it to others to find the venue, topic, and presenter.
  6. If a vendor reads this blog and wants to step forward, then please do so.  Of if you want to contact potential sponsors, please do so.  They are certainly welcome, especially if we incur venue costs that the sponsor will pay for.  But this is primarily about increasing the skill levels of our technologies and those making technology decisions, not about selling products.

The OWASP group has a pretty good speaker agreement that I believe we could copy for this group as well.  Perhaps a similar agreement from venue host and sponsor would be helpful. https://www.owasp.org/index.php/Speaker_Agreement

Who wants to see this happen?  Who wants to be a driver to make this happen?  Let’s make the software developers in the Kansas City metro the best in the world!

Posted in CodeProject, Coding, Project Management, Resources and Tools | Leave a Comment »

The Importance of your Development Context

Posted by robkraft on August 9, 2011

Development context places the primary constraints on the priorities of product development.  As a developer, you can provide more satisfaction to your users when you understand the development context you are working in.  Some developers are not even aware that context exists and that context makes a difference.  These developers can be found at local user group meetings and on forums adamantly declaring that their approach to solving a problem is the only right approach.  But development context is important and it does influence the best approach to solving problems.  An extreme context example is the difference between developing the software that keeps a person on life-support alive, and developing software for your personal use to keep track of your collection of rare coins.  I’m sure you can identify many aspects of the development process that will vary between these two extremes.

Both development teams and projects have a context.  Most often, the context for the development team and every project is the same, but occasionally the development team may be thrown a project that needs to follow a different context than their usual development.  Being aware of the different context opens team members to new approaches to solving to the problem that may be more efficient than the usual development process, and that may provide a learning opportunity.

I have thought of a few contexts that influence the development processes:

  • Quality versus early to market.  In some contexts it is more important to release features to market, even unfinished or unpolished features than it is to provide a robust, bug-free, fully-featured product to the client.  Quick to market features sometimes help eliminate development waste.  How so?  When you don’t bother to spend the time to polish a feature (spell-check, languages support, tab orders, font sizing support…) and then you discover that clients want the UI to look a lot different; you have just saved the time that you would have wasted polishing a UI.
  • Some development teams develop core business applications year after year, but then receive one project that is different.  Perhaps it is a one-time program needed to collect and report on some data, and then the program will be thrown away.  Perhaps the program is only used by one individual.  Such a program may not need the same level of Q/A, documentation, user testing, auditing, logging, security, etc. as the core business applications.  This is another example of context difference impacting development architecture and processes.
  • Another aspect of the development context is the attitude toward new technology.  There is no correct attitude, but each attitude has its benefits and drawbacks, and each project and development team should clarify the attitude for each project.  By attitude, I am referring to the choice between using tools, techniques, and processes that you are familiar with, that are more predictable, and that incur less risk OR choosing new tools, techniques, and processes in order to keep up with the times, take advantage of ways to improve quality and speed development (usually after a learning curve).  Some teams strive to stay on the cutting edge, others prefer to make no changes, especially to valuable stable core business products, and some teams prefer to limit their pace of technology adoption to the things offered by their main technology provider such as Microsoft.
  • Occasionally self-education and learning affect the processes, architecture, and tools used for a project.  Some examples include implementing a project using SCRUM when your normal development process does not use SCRUM.  Using Test Driven Development (TDD) is another example.  Using a new DBMS or programming language can affect your context, as can a switch to using IOC containers, MEF, MVC, or MVVM.  When part of the project goal is to learn something new, it can reduce development speed and introduce quality defects.  Project managers should be more tolerant of quality defects and deviations from the usual development processes as new good practices are discovered in response to the changes.

I think it is worth repeating that the development context affects a lot of things, particularly requirements gathering, quality assurance, documentation, user testing, application logging, application security, application auditing, and more I’m not thinking of.

What else do you know that alters a development context, and thus the way we develop the software?

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

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 »