Aim for product excellence, not project completion

While it’s important to execute projects well, the true measure of success lies in the quality, impact, and longevity of the product, not the completion of the projects that built the product. Sacrifice a project for the good of the product.

If you have been working on a software development project that you expect to take three years to complete, and you learn something new along the way, or a new technology like chap-gpt comes along that gives you new ideas, don’t be afraid to cancel the project and call the project a failure. The product is more important than the projects used to build it. Always do what is best for the product, even if it means a project is delayed or cancelled.

How Does Your Development Team Decide What To Do Next?

What feature should you work on next?

When the product owner provides a well-groomed backlog, you may think selecting the next feature to work on is obvious, but often it isn’t.  A development team should consider many factors before picking an item from the product backlog to work on.

Here are some examples of how features may be selected for development:

• Product Owner in Charge. In some contexts, [what is a context?], the development team is treated as an assembly line to deliver features, and the development team has little or no input into which features they will work on. A drawback of this context is that the development team isn’t allowed to provide an alternative sequence of features that could minimize development costs and increase throughput and quality.  Additionally, allowing the development team to have input on the decisions can increase their commitment to completing the features as well as strengthen their “buy-in” to the product and process, which is known to increase morale and quality.
• PMO in Charge. In some contexts, the development team supports several products and may work on features for a different product each iteration.  In contexts where the development team has some input into feature selection decisions, it is often beneficial to the team to establish a Product Management Office (PMO) that works with each Product Owner to get a consensus agreement from the Product Owners choosing which feature, which Product Owner’s product, will get some development time during the next cycle.  When the delivery team works on feature requests directly from customers, the team may find it helpful to establish a customer advisory board (CAB) that receives most of the large requests and provides input and direction to the development team about which features will be most valuable for most clients.
• Too Many in Charge. In some contexts, development teams switch from feature to feature as their bosses, managers, and clients demand they stop working on one feature and switch to another to satisfy the demands from a specific customer or the whims of a forceful product owner or manager.  Many drawbacks and inefficiencies exist in such a context.  Developers are often demoralized by the inability to finish what they start so output is below expectations and quality is poor.  Context switching wastes time as developers need to re-acquaint themselves with something new and lose the design ideas that existed only in their heads for the features they had been working on.
• Waterfall. In non-agile environments, new projects and feature requests may get delivered to the development team(s) with the expectation that an expected delivery date for the feature will be provided soon even though none of the Product Owners have an idea of the current backlog for the delivery team.  Equally unfortunate is the fact that the delivery teams may stop the feature development on other products when the new request comes in because they are more interested in learning what the new feature is, and they will spend time doing some design and development on it to return an estimate of the expected delivery date.
• No One in Charge. In contexts without delivery expectations or engaged product owners, developers may drift into spending a lot of time developing features that are very unlikely to ever be used, or in developing features completely different than what the product owners expected.  Additionally, developers may context switch often, working on one feature for a while and then another, leaving them with much started and nothing completed when the product owner eventually asks to see some results. 
• Customer in Charge. Some contexts have a particularly demanding or upset client that seems to be dictating the features a team will deliver.  I once worked on a team where we obtained a new client (I will call them ACME), our largest client ever by far, and they soon demanded software improvements to help them meet their needs.  So over the course of two years most of the features we delivered were those requested by ACME.  We even joked that our developing methodology was ADD (ACME driven development) as opposed to Business Driven Development (BDD) or Domain Driven Development (DDD).
• Development Team in Charge. Finally, in contexts where the team wants to work on the features with the greatest return on investment (ROI), developers often collaborate with product owners to calculate the ROI of each feature, providing a value for the feature from the perspective of those who will be using the software, and the developers providing an estimate of the difficulty to deliver the feature and the risks involved.  Minimal risk, easy to develop, high value features are usually developed first; and high risk, difficult to develop features are delivered later even if their value is high.  The textbook formula for ROI is value divided by development cost; and those with the highest ROI scores should be worked on earliest.

The Optimal Context

The optimal context for obtaining the best ROI from software development is a context in which the development team wields the majority of the power to decide the sequence in which features will be developed. The reason for this is the development team has the best knowledge of the changes needed to implement a feature and can suggest the best sequence of feature delivery to minimize development costs.  In a healthy context, the development team will desire input from the product owners to identify the features with the highest value and attempt to deliver those first, and the product team will understand and usually be happy with the decisions made by the development team.

However, there are some contexts in which someone other than the development team can make better decisions about what to develop next. One context is during chaos caused by bad software that needs to be fixed immediately or important clients and customers threatening to leave if their demands are not met quickly. Another context is when the team is comprised of junior developers or people new to a product. In this latter context, it may be best to allow the product owner to determine the sequence in which the team will work on features until the team has learned the software architecture, development processes, and product domain.

Return On Investment (ROI) for Feature Selection

Although several of the contexts listed above may include the ROI (value/cost) when assigning the priority of feature development, the last context, Developer in Charge, is usually the context that provides the most accurate ROI calculation. The reason for this is that both the value and cost of a feature not yet developed change over time, but, with exception of time-sensitive features, the costs of a feature usually change more significantly than the value. The cost of developing a feature can be affected by many factors including:

• The sequence in which features are delivered. In some cases, Feature A may be estimated to cost 100 hours to develop, and Feature B may be estimated to cost 40 hours to develop after Feature A. But if the sequence is reversed, and Feature B is developed first, B still costs 40 hours, but Feature A can re-use some of the code developed by Feature B and Feature A only costs 80 hours to develop.
• The specific individuals assigned to do the work affect the cost, often substantially. A feature assigned to a junior developer available at the time may take 100 hours, whereas a senior developer may be able to deliver the same feature in 20 hours. Waiting for the senior developer to be available at the next iteration may be more efficient.
• As developers write code and learn new technologies they sometimes discover a new approach to implement a feature that was previously not considered. The new approach may not only take less time, but also result in higher quality. This is one reason for delaying many technical decisions until you have more knowledge.

Hopefully, it is obvious that delivering the features with the highest ROI is most valuable to the company.  If your organization is not using ROI as a factor in choosing what to work on next, then your team may be wasting time (as explained in Lean/Agile development philosophy), by not doing what is most valuable first. Allowing the development team to be the primary selector of the sequence in which to develop features may require a change in your team and company culture, and how management hierarchies are organized; but it may be necessary to become more efficient.

Challenges of Calculating ROI

At this point you may accept the premise that choosing features to work on based on their ROI is so sensible that everyone should use this approach, but the reality of software development is much more complicated.  First of all, determining the ROI of each feature is very difficult.  Developers know that estimating the time to deliver a feature is difficult but assigning a dollar amount to the value of a feature delivered may be even more difficult.  So not only are both the numerator and the denominator of our ROI calculation fuzzy numbers, there is also a lot of room for variance within those two values.  What is the ROI for delivering an order entry screen without date pickers for the date fields versus an order entry screen with date pickers for the date fields?  What is the ROI of delivering a grid full of data that lacks the ability to filter the data versus a grid full of data that can filter the data?  What is the incremental development cost of adding each desired sub-feature to the feature?  Can you first deliver a basic set of features and the later deliver the enhancements?  All these options and variables make ROI calculations for a single feature very subjective.

Challenges for using ROI for Feature Selection

• You need to take time to perform ROI calculations and record them with the feature in your tracking system.
• You need to have the people that best know how to value the feature from the customer perspective available to provide an estimated feature value.
• You need to have the people that can best estimate the cost and risks of delivering the feature available to spend time to calculate an estimate.
• The value of an undelivered feature can change over time as market and user needs change or as other options become available that help customers and users resolve their business needs.
• The effort required to deliver a feature can change over time as the skills and knowledge of the developers change, but also as the technologies and frameworks of the software evolve and improve.
• The cost to deliver some features may be reduced when the feature is delivered along with other features.  Imagine having three separate requests to add a checkbox for different purposes to the same user interface, and the value of the first checkbox is deemed very high, but the value of the other two checkboxes is not.  Each has the same development cost to deliver.  However, if all three are delivered together the development costs decrease significantly because all three database changes can be made at once, and all three business object changes can be made at once, and all three UI changes can be made at once.  Therefore, given that the cost of implementing checkboxes two and three, when implemented along with checkbox one, is reduced significantly, the ROI of checkboxes two and three would increase and it would make sense to deliver them along with checkbox one.
• Another reason to implement features with lower ROI is to use them as a test case for a new technology.  Perhaps you know you want to start encrypting data for millions of transactions, a feature with a lot of risk if it is delivered incorrectly.  Therefore, you choose a lower priority feature from the backlog that also needs to encrypt data, but only in a small number of use cases.  You can implement the feature with the lower ROI first to work out the difficulties of implementing the new encryption technology before using it on a more important feature.
• There are more reasons for choosing to work on features that don’t have the highest ROI, and some of those reasons include:
  • You have a developer or two that need to be assigned some work, but the developers don’t have the skills to tackle the features with the highest ROI.
  • You have a junior developer or intern, and you want them to comfortably work on some features that will help them best learn your software and development processes; or you want them to work on some features that won’t have a significant impact if the developer makes a mistake.
• ROI includes a time component. Value may decrease over time.  One feature may provide a greater ROI initially, but another feature may provide a greater ROI over a longer time period.  If a feature is working poorly in Windows 8 but works perfectly on Windows 10, the longer you wait to deliver the feature the less value the feature will provide when finally delivered because more of your customers have migrated to Windows 10. 
• ROI value may increase over time. We might estimate the value of a feature to be worth $50,000, but it may be more accurate to say that the feature will increase our revenue by $1,000 per day, thus its value is increasing over time. So, when we calculate the value for ROI and compare the ROI for two features, we need to consider the timeframe of the ROI for each.
• Developers often prefer to work on features that provide the best ROI in the long term, which can include rewriting some old, buggy, difficult to maintain software using current frameworks and technologies.  But if customers are angry and demanding the bugs get fixed ASAP, it may be best to spend time fighting the current fires, knowing that the very code you are fixing will be thrown out and replaced within a few months.  It feels like a waste, but you must survive the short term to exist in the long term.  If that phrase doesn’t make sense, consider this analogy:  Fighting global warming may be the most important challenge we face and where we should focus our resources, but if the largest nations in the world are on the brink of a nuclear war, then focusing resources on resolving that challenge in the short term becomes more important than fighting global warming; because if don’t deal with the short term problem, no one may survive to address the long term problem.

Should the Development Team Do Activities Other Than New Features?

Some readers may feel there is a lot to consider to effectively use ROI to drive feature delivery but using ROI to determine what a development team does next is only part of the equation.  There are activities you may find more valuable to your development process to work on instead of developing new features. If you have adopted a Continuous Process Improvement mindset, then, by definition, you believe you should often spend time considering how you can improve your processes; and in this context how you can improve your software development processes.  What if you could make a change to your software development process that would increase delivery speed of new features by 50%?  I suspect you would want to implement that change.  But that change is not a new feature.  It is more likely a DevOps change or a significant refactoring of the code, or a process change such as adopting Kanban.  Regardless of what the change is, the change is likely to require time from your developers to implement and adopt.  That means that instead of developing new features, your developers are going to spend their time on other activities.  We now realize that there are activities other than developing new features that your development team should consider spending time on.  Specifically it means that your software product and delivery process will get a better ROI when the development team performs activities like improving DevOps, fixing bugs, refactoring code, training, writing unit tests, and writing developer documentation than when they are developing new features.  This is not to say that these activities always, or even most of the time, provide a better ROI than delivering new features, but it does mean that when the decisions are being made about what the development team should do next, the decision makers should not be considering only new features to deliver.

Evaluating the ROI of Possible Development Team Activities

The following diagrams provide examples of a backlog of activities that a development team could perform. The backlog has four types of items: New Feature, Fix Bug, Refactor, and DevOps change. In the upper half of the first diagram, the team chooses to implement a New Feature that has a development cost of 2, and the value perceived by the customer receiving the feature is 12 (100 – 88).

In the lower half of the above diagram, the development team chooses to fix a bug. The bug has a cost of 3 and increases the customer’s perceived value of the software by 2 (102 – 100). For both developers and businesspeople, the examples above are easily understood.

The following examples attempt to convey the value of Refactoring, DevOps Changes, and Training using the same principles of ROI.

In the upper half of the diagram below, the development team chooses to refactor some of their existing code. This code is delivered to production, but the customer perceives no value in the change (102 – 102 = 0). From the perspective of the customer, the features of the software have not changed (although in some cases refactoring may include noticeable performance or security improvements). But what you should notice is that the cost of several items in the Backlog changed after the refactoring was implemented. The most common effect of a successful refactoring is that delivering future features becomes easier. Of course, as with ROI calculations, it is difficult to estimate the impact on cost that a refactoring will have on other features. Additionally, refactoring code to support a newer framework or technology may be beneficial to changes made a year or more in the future, but not particularly valuable to the other features in the immediate backlog.

The lower part of the above diagram begins to show the impact of a change in DevOps. For purposes of this article, a DevOps change refers to a change made to the processes and tools used to build, unit test, validate, and deliver software. A DevOps change could imply that the team took time to automate builds instead of performing manual builds, or to automate deployment to a test environment so the QA team could test the latest build more quickly and provide feedback more quickly. Regardless, the DevOps change does not (in the case) affect production, and there is no deployment. The customer does not gain any direct value from the DevOps change. But, like refactoring, the DevOps change has a positive impact on subsequent development as shown in the diagram below. In this example, the Cycle Time, the speed at which a feature goes from “started” to “delivered” was reduced for most features developed after the DevOps enhancement. By investing time to make this DevOps improvement, all future development can be delivered faster. In this specific, admittedly fictional, example, the time for a feature with a size Estimate of “8” has been reduced from 25 to 22, the time for a feature with a size estimate of “5” reduced from 12 to 10, the time for a feature with a size estimate of “3” from 5 to 4; while the estimate for a feature with a size estimate of just “2” remains at 2.

One additional activity included in the lower part of the above diagram is developer training. The impact of developers taking time for training, such as learning new design techniques, coding techniques, or development product features, may be to increase the speed at which developers can produce features. So, like refactoring and DevOps enhancements, a team may consider developer training to be the activity that it is most valuable for a development team to do next.

Doing Multiple Things At The Same Time

The entire article up to this point assumes that development teams do one thing at a time. In reality, teams with more than three people usually do several things at the same time. Most teams, even many Kanban teams, will pick several features, bugs, and other activities to work on over the course of a few weeks, or during the next iteration. One benefit of doing multiple activities is that some team members are usually always working on new features, which is what product owners and customers are primarily interested in. Working on multiple activities at the same time allows some feature progress to continue even as other team members spend months on DevOps or refactoring activities.

Recap

• There is value in understanding who decides what the development team will do next.
• There is value in recognizing that the development environment context strongly influences who makes that decision.
• Return on Investment (ROI) should be a primary factor in determining what is done next.
• Developers usually can provide the best ROI estimates.
• ROI is a subjective measure.
• Activities such as refactoring and DevOps improvements may provide a better ROI than developing new features.

The Elements of Software Development

Elements of Software Development

Successful software products and solutions rely on much more than the programming source code put into them.  The elements attempt to identify all the factors that affect the outcome of a software development project.  The value of recognizing each of these elements is to help those involved in a software development process recognize that many elements influence the production of quality software, and each of these elements should be evaluated if you desire to improve your software product and software development processes.

Most people accept, as self-evident, that any process has room for improvement.  The CPI (Continuous Process Improvement) mindset encompasses many programs and frameworks that accept that people can always do better and can systematically attempt to do so.  If you agree that improvement is possible, it follows that you also recognize there are many areas in which improvements can be made.  We can’t make all possible improvements simultaneously, therefore we must select a few things to improve and start those before identifying and working on other areas of improvement.

The elements give us places we can look to consider making improvements.  We will find that it is easier to make improvements in some of the elements than in others, but we should also consider which improvements provide the best return on investment (ROI) when undertaken.  We hope practitioners will examine each of the elements and consider if changes could be made that would improve their software development process and product, and direct their energy to those changes that will most likely be successful and provide the best ROI.

The elements of software development are the things that influence how software is developed.

Each element has been assigned a category, either Product, or Process, or People.  Elements assigned the people category are elements that affect the development of people.  When you make a change to one of the people elements, you are usually making a change that you hope will improve a person or people.  When people have better training, experience, tools, and workplace satisfaction they are more likely to produce better software.  Elements assigned the process category are elements that are used to produce the product, but that are not present within the product delivered to the client or people that use the product.  Agile methods and DevOps are two very notable elements assigned to the process category that have a significant impact on the successful delivery of a quality product.  Of course the elements of the product category include those things the customers interact with, including training and support along with the quality of the software.

_{Product is what the customer is buying; process is how that product is created; people are those using the process to create the product.}

^{On nomenclature:  The word element and category are lower case for a reason.  There is nothing special or significant in the choice of these words.  The word element was selected primarily because it is less used in software literature than many synonyms that could have been used such as component, factor, feature, or module.  Likewise, category is used extensively in the domains of many fields, but in this article it is a simple term used for grouping some similar elements.}

The Software Development Life Cycle (SDLC) has long been considered the list of steps followed for the production of software.  The elements makes no change to that.  The elements identify additional factors that influence how software is produced and that affect the success or failure and quality of the software.  Nine of the elements are noted for having a close correlation in meaning to a step in the SDLC.

_{SDLC is the name for the process we use to get from Idea to Solution.}

The first purpose of the elements of software development is to help us identify where we might spend our time to make improvements.  The second purpose of the elements of software development is to help us identify the current context in which we develop software so that we may make better selection of practices and processes that will lead to success.  There are hundreds of practices and processes to choose from to use during software development, and much debate about which practices and processes are best.  The truth is that the value of any specific practice or process depends a lot much upon the context in which it occurs.  Perhaps this is best understood from this example:  Some software developers believe strongly in CI/CD and believe that all development teams should make it a goal to deliver software continuously.  However, other software developers work in a context where that is not possible.  For example, continuous delivery of software embedded into gyroscope controllers on a Mars rover craft is impossible.  Even for many contexts where it would be theoretically possible to apply CI/CD, the benefits and risks are not worth the cost of doing so.

The value of a practice or process must be considered within the context in which it is applied.  Of the twenty-five elements, all but three contribute to the context in which software is developed.  Therefore, when we consider the use of a different process or practice, we should consider our context as a factor that may make that process or practice successful.  Many software development teams have adopted the Scrum methodology in an attempt to improve their software development.  Unfortunately, the adoption of Scrum has not been successful in every case.  But why is that?  Is it because they are doing Scrum incorrectly, or is it because Scrum is not a good practice for their context?  That is a difficult question to answer.  Unfortunately, a few people dogmatically believe Scrum should always be used by all teams, and that could be based on their own lifetime of experience, which could be all within similar contexts.  These people then may continue to push Scrum even when it is not the best choice in a different context.  This is the outcome we hope to avoid when practitioners consider the context into which they are attempting to apply a practice.

The context for software development for a team reflects the collection of twenty-two of the elements.  The context is the interaction of these twenty-two elements.  The implication is that you should ask if the practice you are considering to adopt is a good practice for your context.  Is it a good practice that aligns with your choices for each of the twenty-two elements that apply to context?  A few examples of processes and practices, Scrum and CI/CD, were already mentioned.  Other examples of processes and practices include Test Driven Development (TDD), Pair Programming, Unit Tests, Automated Builds, Kanban, Retrospectives, Estimates, Metrics, WIP Limits, Story Points, StandUp Meetings.  There are many more.

The hope is that we can use the identified context to make a good selection of practices.  Here is an example that considers just a few of the context elements along with the question, “Should we develop software using TDD?”  If the “Team Composition” is “junior developers”, and the “application architecture/design” is “unknown”, then asking them to use TDD when they have not done so before may be very valuable to achieving good results.  But if the “Team Composition” is “senior developers”, and the “application architecture/design” is “well known”, then asking them to use TDD when they have not done so before may be detrimental to the results.  TDD, or any other practice or process, is not inherently always good or bad, but these patterns and practices work better in some contexts than others.

_{Context is the collection of factors that influence the choice of best practices for your software development processes.}

The twenty-five elements of software development are used by most software development teams, but not all.  For example, software developed by a single person is unlikely to have a “Hiring Process” element.  However, for each of the twenty-five elements, a software development team made a choice about what to use within each element.  Here are a few examples.  For “Architecture”, the choice could be a web application, desktop application, embedded application, or another architecture.  For “Project Management”, the choice could be Scrum, Kanban, Waterfall, or another process.  Every software product under development is being developed in a specific context, and that context affects best practices.  Many people probably also understand that the context is rarely static.  A team that is developing an application using one process many also be transitioning to developing the application using a different process.

As mentioned previously, it is probably counter-productive, destructive, or simply impossible to systematically make changes to all the elements of your software development at the same time.  You must select some to begin improving, which means you must choose those that are most valuable to change first.  Even when someone can show you that there is value in changing the way you handle one of the elements, you might not begin making that change because there are more valuable things to focus your efforts on.  The one limiting factor that all software developers share is limited time.

_{We have a limited amount of time to spend on creating software and improving processes before the results of our efforts becomes obsolete.  Therefore we must choose wisely how we spend our time.  What changes will produce the most benefit, do the least harm, or introduce the least risk?}

The elements of software development are shown in a list that includes some questions related to each element to help developers understand what they represent.  Future articles will cover each item in more depth.  Another track of future articles will look at software development practices one by one and consider which implementations of each element could be benefit from the practice and which it could be a detriment to.

A PDF version of the content of the images above is available online at https://kraftsoftware.com/ElementsOfSoftwareDevelopment.2021.8.16.pdf

Efficient Software Development Surpasses Both Waterfall and Agile Development

A product owner asked a developer to add a date picker to the web site in place of a text box. The product owner said it would be nice if the calendar just displayed the five weekdays. The developer knew he could add a date picker but didn’t know if he could exclude Saturday and Sunday from the calendar. He didn’t find any options in the date picker control to exclude the weekend, so he created a new control. It did not render as well across all browsers, and behaved a little quirky sometimes, but it showed only weekdays. This took the developer two weeks to complete, after which he showed it to the product owner. She was not happy with the rendering problems and was very disappointed to learn it cost two weeks to develop. The product owner said she would rather have a control that worked better even though it included weekends, especially if that control only cost a few hours to implement.

The parable tells a tale of software development. It is a sad tale, and a common tale. Many would consider it an example of a project failure. The product owner paid more money than expected for a solution that was not as good as she hoped it would be. This type of problem occurs often in waterfall software development, but it also occurs in Agile software development.

Yet, this problem could have been prevented. The developer and product owner should have communicated more frequently. The product owner should have made it clear that she would like a calendar that excluded the weekdays, but only if it could be completed by adding no more than two additional hours of development. And the developer should have understood that the business is usually willing to settle for less than the asked for if the price of getting exactly what they asked for increases the cost exponentially.

Teams that desire to develop software more efficiently will identify this communication problem and make attempts to reduce the chance it will happen again on future projects. The teams will do this as part of their goal to improve their processes, not because the Agile principles provide this guidance. Software developers should strive to develop software more efficiently, and if following Agile principles helps facilitate that improvement then software developers will follow the Agile principles, but it is important to avoid putting the practice of following Agile principles ahead of efficient software development. Agile principles are a tool we can use to develop software more efficiently, but Agile principles are not the goal of our software development process. Great software developers don’t care if someone considers their processes to be agile or not agile, as long as they are efficient. I feel it is important to stress this last point, because it is the key takeaway from this article: Our goal is not to become an Agile software development team; our goal is to develop software more efficiently.

Developers that already practice Agile development may recognize that the characters in the parable were not following Agile principles, and if they had done so, they would have experienced better outcomes. That is certainly true if the teams were following the principles of Agile, not just some of the common practices. Too often, companies, project managers, scrum masters, and developers adopt practices such as “Daily Standup Meetings”, “Two-week Iterations”, “Retrospectives”, and “Measurement of Velocity” and believe that makes them Agile. But none of these practices would have solved this problem. Following these practices does not make a team is Agile, nor is being Agile the goal. The goal is efficient software development. Agile principles can help you get them, but don’t let your focus on Agile principles cause you to lose site of the goal.

Trello Removes Feature for Creating Personal Board – A Setback From Their Atlassian Acquisition

I discovered today that Trello no longer supports personal boards.  When you create a new board you need to create it within a Team first (teams will be renamed workspaces).

You can get around this by just creating your own team, perhaps name your team Personal.  But I see this as the first of many steps where Atlassian is re-purposing a popular tool for personal time management into a product optimized for users of other Atlassian products.  It is sad when a good product is acquired by another company then altered for different end users.

As I suspect more changes in the future, probably even pricing related, I am hunting for alternatives to Trello now.  There is a good list of some in this article:  The 17 Best Trello Alternatives in 2021 (In-Depth Comparisons) (kinsta.com)

Asana and Wrike are a few good alternatives.

Here is Atlassian trying to put a positive speed on their product degradation: Why can’t I create a board outside of a team anymore? – Trello Help

The Project Management Triangle Fails To Value Uncertainty

Most students of Project Management are familiar with a decision making tool known as the Project Management Triangle.  It is also known as the Iron Triangle, or the Triple Constraint.  The concept provides a mechanism for the product owners to make decisions.

In a nutshell, the concept states that you may control two of the three project factors (Time, Cost, and Scope/Quality), but the third factor is mostly out of your control.  Therefore you can:

• Have the project fast and within scope (all features desired), but then it may exceed the desired cost,
• Have the project fast and within cost, but then you may not get all the features in scope,
• Have the project within cost and within scope, but then you may not get it on time

The Project Management Triangle is used by project managers in many industries, but in software development another factor often needs to be considered when making project decisions and that factor is uncertainty.

Uncertainty

Uncertainty doesn’t fit neatly in the Project Management Triangle.  Nor can you simply change the triangle into a square by adding uncertainty because uncertainty is not affected consistently with changes in the other three factors.  A decision that increases uncertainty may increase the time, increase the cost, decrease the quality, or even do all three.  Conversely, a decision that increases uncertainty could have the opposite affect on any or all of the sides of the triangle.

Side Note: Quality as Part of Scope

I believe that scope includes the aspect of quality.  There are two types of software quality.  One is the richness of features as seen by the users of the software.  The other is the robustness, integrity, and ease of maintenance of the code, deployed solution and ecosystem the solution runs in.  Scope can be easily equated with the quality visible to the users of the software.   But the quality of the ecosystem and maintainability of the source code is not so easily identified by users of the software.  Even so, for purposes of this article, I think that both types of quality can be included within scope.

The problem with the introduction of uncertainty is that, by definition, the decision makers don’t know if the detrimental effects will come to pass; only that detrimental effects are more likely to happen when uncertainty is introduced.  Therefore decision makers must decide if the change that is intended to reduce cost, reduce time, or increase quality, is worth the uncertainty that comes with it.

Proactively Reducing Uncertainty

Some decisions reduce uncertainty.  In fact, project managers sometimes deal with risks by creating a new project to explore the uncertainty and eliminate the risk it entails.  I hesitate to call out benefits of the waterfall methodology of development, but risk reduction might be a step more easily adopted in waterfall, as opposed to agile, because waterfall is more likely to identify and consider the risks at the start.  This allows for developing a prototype to test the use of a new tool, component, or framework, in order to understand it better and reduce the uncertainties.  For Example, NASA reduces risks to its human astronauts by first launching unmanned rockets instead space.

Acknowledging Uncertainty

In the world of software development, we often must choose the solution to a problem from a menu of options.  Some options increase quality but at the cost of time.  Others decrease time but at the risk of quality.  And some increase uncertainty, particularly when the option introduces a new technology, tool, or process.

When a project has a tight deadline, a team should be less willing to risk an option that introduces new technologies, and thus uncertainty.  Also, when a project has high visibility or life-endangering impact, a team should be less willing to risk an option that introduces new technologies, and thus uncertainty.

Here are some examples:

• A team discovers a defect during product development.  The team can choose a quick fix, which is to log an error message to a local text file, or choose a more robust fix, which is to log the message to a cloud-based service.  The robust fix is more desirable but might cause failures for some clients that implement the product in unexpected environments.  Is the team willing to accept the risk of the robust fix, or should they implement the quick fix and take more time to test and prove the robust fix before providing it in a future release?
• A team chooses a technology they have not used before.  They choose to use .Net Core instead of the .Net Framework.  They accept that there are uncertainties, which means risks, to successfully developing with the technology as well as deploying it and supporting it.  They develop successfully but when they deploy they discover .Net Core is not supported on the server they deploy to.  They realize they need to upgrade the OS on the servers in order to support their application, but the IT team won’t be able to perform the OS upgrade for several more months.  This may be acceptable, but if the team had a tight deadline for the project then perhaps this project was not a good candidate due to the uncertainties that came with the new framework.
• A team chooses a stronger encryption technology for the next release of their software.  When the software update deploys to some desktops it fails and the end users are unable to use the product.  The failure occurs because the encryption algorithm, a new technology thus containing uncertainties, is not supported by Windows Vista, an operating system that some customers still use.  You can probably guess how I came up with some of these examples. 🙂
• A team chooses to skip significant testing of the software in order to release on time, within budget, while providing the scope desired.  Most all members of software development teams can tell you that inadequate testing increases the risk that the software will encounter problems in production use.

In the course of my career we have often opted for one solution over another not because one solution would reduce cost, reduce development time, or improve quality.  Instead, the solution we chose was the one with the least risk.  This was usually the choice when our release deadline was near and we did not want to introduce uncertainties.

Mitigating Risks

A technique we use to reduce the negative impact of risks is to use the new technologies  in minor features in our applications.  For example, when deploying a new logging framework we used it only in one minor component.  When we created a framework for sending emails via SMTP we only used it in an optional feature.  As we grew confident with the new technologies and increased their robustness, we expanded their use across the application.

Here are a few good articles about the traditional benefits of the Project Management Triangle:

https://rapidbi.com/time-quality-cost-you-can-have-any-two/

https://en.wikipedia.org/wiki/Project_management_triangle

Programmer’s Dilemma – Should you fix bugs before adding new features?

The Scenario:

The purchase order web app worked very well for the first four departments that used it, but when the art department tried to use it they experienced some problems.  A few features, printing and file uploads, did not work.  The art department liked the app despite the problems, but they felt they could be more productive if all the features worked for them.

Developers determined that differences in the way the Safari browser behaved on touch tablets caused the issues.  The other departments used the Chrome browser on desktop PCs.  The two developers estimated that it would take them a month to rewrite to app to work on Safari also.  However, the two developers had several new projects queued up to work on.

Should the developers fix the first app to work on Safari before starting work on the new projects?

Let me provide you some additional information for consideration.

The developers have six new projects queued up, each will take them about one month to complete, and each is each estimated to save the company $50,000 per month when completed.  Fixing the bugs in the first app to work better on Safari will make the art department more productive and save the company about $5,000 per month.

Based on this information, you could reasonably conclude that the return on investment of completing the new projects is higher than fixing the problems on the first project.  Therefore the developers should complete the next six projects before considering fixing the first project.

 

But let me provide you even more information to consider.

What if the knowledge gained and the frameworks created fixing the first project could be re-used across the next six projects guaranteeing that all projects work on both Chrome and Safari?  And what if the next six projects are public facing and therefore likely to be used by people using IPhones with Safari browsers via a touch interface?  The developers might be able to create the future apps more quickly and with higher quality.

Additional information may make decisions more difficult, but these are examples of the challenging decisions we face in software development.  Many variables contribute to our decision and most variables can’t easily be measured in dollars and cents.

I once attended a meeting with several customers of our software application.  We had a list of projects we could work on.  Some projects were for adding new features and others for fixing problems.  I’ll never forget what one business owner said, after another business owner had just argued that some of the problems in the software were costing them money and needed to be fixed first.  He said:

“I think of my company like a bucket with holes.  It has water, in the form money, pouring into it from the spigot, but it leaking.  We can spend time fixing the holes, or we can run the water faster.  Which way will get the bucket full the fastest?”

More succinctly, “Which course of action provides the most value?”.  That is the question we should be asking ourselves with every decision, every day.

Side note:

Shouldn’t we always fix bugs before adding new features?  Some development teams follow this philosophy but each team should decide for themselves if that is the right philosophy for them.  Fixing bugs before starting new features is more valuable for features that have not yet been released than when addressing bugs after they have been released.

Programmer’s Parable – Gathering Requirements Up Front

 

The business owner asked the software developers to build a new web application for a single client.  She said that the web app needed to be really fast.  She told the developers this could be the first version of a new product that the company would build upon for years to come.

The developers were excited to work on something new.  They wanted to put their Agile skills to use and see if they could deliver the product within the expected two months while hitting their quality and performance goals.  They wondered what the product owner had in mind for the future beyond the first two months, but she was not readily available so they figured they would follow the Agile practice of focusing on one thing and getting it completely done before thinking about future features.

The team built a great site on time and within budget.  They cached as much data as possible to make it really fast.  The business owner was pleased.  The customers was pleased.  The developers were pleased because they had made everyone happy.  But the cloud IT manager was not pleased.  He noticed the price charged to the client barely covered the hosting cost of running the application in the cloud.

At the party to celebrate the success of the web site, the cloud IT manager asked the business owner if she had a plan to reduce the hosting costs so that the return on investment (ROI) could be earned more quickly.  She laughed and said, “Of course I have a plan to improve ROI, but it is not by reducing hosting costs.  Now that we have one client on board, I’m going to have the team add dozens more clients to the same web site.  The incremental cost of adding each new client should be trivial, just like it is with our other products.  Once we have more clients, the hosting costs will seem trivial!”  She walked away to talk to someone else without recognizing the doomed expression upon the faces of the developers that overheard the conversation.

The Scrum Master saw the developers looking sad.  He asked them why they looked sad.  A developer replied, “She said she wants us to add more clients to the application.”, to which the Scrum Master replied, “Yes, I know.  It is going to be the top priority in our queue for the next iteration.  But why does that make you sad?”  The developer took a deep breath and said, “Because the only reason our web app is so fast is because we cache so much data on the server to avoid database calls.  The data cached is unique for the client.  We didn’t know that we would be expected to support multiple clients on the same web app.  We are going to have to redesign the entire app to support this.  Plus we don’t know if we can make it as fast as it is now.  If we had planned for the next release when we were developing the first version, we would have been able to avoid the complete rewrite that is now needed.”

Analysis

Is it Agile if you engage in Big Design Up-Front (BDUF)?  The answer to that question is to point out that this is the wrong question.  In software, the question should never be, “Is it the Agile way?”.  The question should be, “What it is the best way?”.  Also, in this parable, the problem is lack of future requirements, not lack of future design.

In hindsight, knowing there would be future requirements, the team should have gathered some of those requirements up front.  Gathering requirements and creating designs for future releases is not “anti-Agile” and does not violate any rules of Agile development.  Getting requirements and thinking about design early is good.  You should only question “the amount of time” you spend gathering requirements and creating designs for future releases; not whether or not you do so at all.  If the time you spend on requirements and design for a future release moves beyond hours, beyond days, and into weeks, then you should become concerned that the time you are spending will become waste.  When that time is measured in a few hours, it is probably well worth it.

https://en.wikipedia.org/wiki/Big_Design_Up_Front

Programmer’s Parable – The Last Minute Decision

The software developers looked forward to making the desktop software available for download tomorrow.  They had worked hard to create a high quality, robust program to support customer needs for many years to come.  The business owner stopped by and asked if they had included the discount on purchases for his brother’s company into the software.  The developers looked surprised.  They did not know about this requirement.  The team lead admitted, “I’m sorry, I forgot about it.  You mentioned it to me when we had lunch a few months ago but I did not write it down.”  The owner, said, “My brother will be one of our first customers, can you add this feature today before we release?”  One team member, a mid-level software engineer, spoke up, “Yeah, I think we can make a few simple changes to show a discount in the desktop user interface (UI) only for your brother’s specific account number and it should work fine.”  The response seemed to please the owner, but the software architect replied to the mid-level engineer, “I’m not so sure.  That may create new problems.”  He continued, addressing the product owner, “We will discuss it and get back with you.”

So, the developers held a meeting to discuss the problem.  They estimated they could modify the desktop program in a few hours as the mid-level engineer suggested to solve the problem in the short term, but what if additional customers needed a discount?  A programmer would need to make another code change and they would need to publish a new version as a patch.  And how would that logic get included into the mobile app they intend to release later that year?  They would have to code a similar workaround there.  They would have to maintain the quick fix code in several places.  Putting a quick fix into the UI introduces risks that the logic won’t be applied elsewhere when needed; it would also be harder to automate unit tests for the new logic; and it would require programmer intervention for future similar changes.  Another option, and the one the architect preferred, was to add a column to a table to indicate the discount, change the stored procedures and business objects to handle the discount; and also create a new user interfaces to allow the product owners to configure discounts without programmer intervention.

The developers made quick estimates and presented these three options to the product owners to make a decision:

Option 1: A quick fix.  They estimated a few hours to complete coding and testing the work.  The benefit would be releasing on time.  The drawback would be a design that contained risks that this business rule is not maintained across the entire code base and that additional patches to the code would be needed if the hard-coded discount changed or needed to be applied to other customers.  Another drawback is that the software architect did not favor this approach and there were already concerns that he was getting frustrated with the company and might choose to quit.  The mid-level engineer however favored this approach because it would work, and it would get the product to the customers faster so they could be happier faster.

Option 2: Delay the release for two weeks to allow the team to improve the design to support discounts that could be configured by business users without future changes to the code.  The benefit would be a design that is more adaptable to changes in product discounts in the future and that the product discount logic could be shared with the mobile app.  The drawback is that they would have to tell the customers the product release is delayed for a few weeks.

Option 3: Perform the quick fix, but immediately start working on the improved design to allow users to configure the discounts.  The benefit would include releasing the product on time, and the architect could get the good product design he was looking for.  However, the drawback to this approach is that it would take four weeks to roll out the product fix with the new design because extra work would be needed to version the API due to the changes required to it and also to migrate the database changes from one version to the next as well as to perform all the upgrade and migration testing.

Which option would you chose?

There is no correct answer, but one choice may be better than another depending on the situation.

If the product is a Christmas promotion application for the year 2020, then the quick fix of option 1 is likely best assuming the program will only be used for a few months before it is discarded.

If the product will help its users start making or saving tens of thousands of dollars every day they use it, then you probably want to get it to them as quickly as possible, thus the quick fix of option 1 or option 3 is likely the best option so the gains can be realized even though a higher cost is placed development.

If the development team has other valuable applications to develop, then perhaps you should choose option 1 instead of option 3 because the return on investment (ROI) of another application is greater than the cost and eliminating the risks than come with option 1.  Perhaps the business has another product that will earn a $100,000 per day once deployed.  Should the developers spend a few weeks or a month making the first product better when it only brings in $5,000 per day instead of starting work on the second product that will earn $100,000 per day?  If the profit earned daily is high, then you should probably lean toward option 1.  If the profit earned daily is low, then you should probably lean toward option 2, assuming the application will be around for years to come.  If developer costs are low; particularly if your developers have nothing else they could be doing with their time, then option 3 is probably a good choice.

If developer morale is important and if the decision seems to have a big impact on developer morale, then perhaps you should accept the approach they recommend in order to boost their morale and increase their sense of ownership in the product.

We, and here I am speaking as a developer myself, often desire to fully complete a product or feature we were working on.  There is satisfaction and value in doing so.  But sometimes maybe it is best to leave some code and applications partly sub-optimal because there are things we could be doing with our time that are more valuable to the company.

In software development we often have many factors to consider in making product decisions.  Rarely are the costs and benefits clearly measurable.  Even time spent in analysis causes a delay in execution and therefore contributes to waste and increased costs, so it is sometimes counter-productive to spend a lot of time in analysis.

 

 

What Makes A Software Programmer a Professional?

Many people write code, but not everyone that codes considers themselves to be a professional programmer.  What does it take to be a professional?  This article lists the practices you undertake when you are a software development pro.  From my experience, many of these practices are not taught in coding schools, but they are essential to delivering quality software to customers.

Before covering the practices, let’s first briefly consider different classes of those who write code:

The Tinkerer
A tinkerer is a person that writes a few lines of code here and there, perhaps a macro in Excel, perhaps connecting services in IFTTT or Microsoft Flow, or perhaps a script to run in a database. A tinkerer may also use a language like basic or javascript in order to create a program or web site for their own personal use and enjoyment.

The Amateur

A programmer becomes an amateur instead of a tinkerer when the programmer starts writing software or web sites for others, especially when the programmer is compensated for their work.  Amateur programmers often create good software and write code well.  But to be considered professional, there are several practices a programmer will follow.

The Professional

The following lists represents what I believe are practices that every professional software developer will follow.  As in all things, there may be some cases where it makes sense that one or two of these practices is not performed by a professional; but I believe most would agree that professionals follow all of these practices most of the time.

1. Use version Control
2. Back up everything off site
3. Track the changes, fixes, and enhancements in each release
4. Keep the source code related to each deployed version that is in use
5. Keep a copy of your software in escrow
6. Use automated builds
7. Schedule builds
8. Write regression unit tests
9. Use a bug tracking system
10. Use a system to track tasks and features being developed
11. Keep customers informed about the progress of the software development
12. Keep third party software used updated regularly
13. Understand the security risks
14. Ensure proper compliance with industry standards such as PCI, HIPAA, SOX, and PII
15. Educate yourself continuously
16. Invest in your development tools
17. Properly license development tools and software
18. Write documentation about the software
19. Keep a journal of your activity

1. Use Version Control

A version control system should be used by all professional software developers.  It is difficult to imagine a solution for which version control would not apply.  Today, most developers use GIT, but many also use Subversion (SVN).  The version control system used should have the following features:

• Allow people to add comments explaining each check in, and track who checked it in
• Allow people to view a history of changes checked in for each file
• Allow people to revert to earlier versions of the software
• Allow people to compare the code changes made across check ins

Zipping up the files that are part of each product release or check in, instead of using a version control system, is a sign of an amateur programmer.

2. Back Up Everything Off Site

A professional programmer will make sure that all of the code they write is backed up regularly, and that back up needs to be an offsite location to prevent loss of all of the source code in the event of a fire, flood, theft, or some other event.  Given the ubiquity of the Internet today this is usually easily achieved.  Simply using an online repository like github or bitbucket for version control almost fully meets this practice in most cases.  Along with the backups of the source code, a professional will make sure that that the scripts and commands for the tools and processes used to build the software is also backed up remotely.  A professional programmer should be able to start from nothing, acquire a new computer, and reconstruct everything needed to continuing developing the software by recovering all of the software from the off site backup.

3. Track the Changes, Fixes, and Enhancements in Each Release

A software professional provides more than software to their clients, they also provide a list of all the new features included in the latest version.  Of course there should also be a comprehensive list of the contents of the initial version.  In addition, a list of bugs fixed and other changes such as noticeable enhancements to performance and security should be provided.  A software professional tracks the reason behind every code change made during a release.  This is often helpful when clients are looking for a feature or fix because you can tell them they need to upgrade to a specific version to get it.

4. Keep the Source Code Related to Each Deployed Version That is in Use.

Modern version control software allows us to see how the code looked at any point in time.  A professional should be able to easily and quickly see how the code looked for any version of the software that any client currently has implemented.  This helps the developer resolve issues reported by clients more quickly, and to create a fix for the software.

5. Keep a Copy of Your Software in Escrow

No one likes to ponder the possibility of their own demise, but as a software professional you should consider this possibility and take steps to ensure that your clients can continue to use your software if something unfortunate happens to you.  Make sure that someone besides yourself can obtain access to your source code and all the artifacts and processes needed to build and support it if the need arises.

6. Use Automated Builds

Building software takes us from the source code to the final output that is deployed to a client or to a production system.  While builds often start out simple they can evolve to become more complicated.  For this reason, a professional developer will set up an automated build process that compiles and combines all the source code to a package ready to deploy.  Minor tasks that can be automated so that they are not forgotten include flagging the code as a release build so that the compiler will optimize the output, or minimize it, or obfuscate it as needed.  Automated builds often update version numbers and also often perform several steps in a specific sequence.  Build processes can be automated initially with simple batch/command files; but many professional use tools specifically designed for building software products.

7. Schedule Builds

Scheduling a build is just the next step, and hopefully a minor step, after a professional has created an automated build.  Many developers schedule a build to automatically run once or twice a day.  This is especially advantageous when multiple developers are contributing to the code.  Some developers even configure the version control system to start a build every time code is checked in.  Frequent builds help developers identify bugs more quickly if an artifact necessary for the build was excluded from their repository checkins, or if code they checked in adversely affected code in another part of the system.

8. Write Regression Unit Tests

I’ll admit that there may be a few cases where it does not make sense to write unit tests for your software.  But I believe that in almost all cases, even for old languages like Cobol and Visual Basic, a developer will write unit tests to validate important logic in the software runs correctly and is not inadvertently altered by a new enhancement or related bug fix.  Getting a unit test framework up and running takes a few hours or even a few days for someone not familiar with unit tests, but once you have it, you find that the tests give you a lot of freedom to make changes and the peace of mind that the changes you make are not breaking existing logic that your customers depend upon.

9. Use a Bug Tracking System

Let’s face it, almost all software has bugs, or things that are not working quite as the user desires.  Software developers need to track when those bugs were discovered and who discovered them so that they can make a careful fix and provide a patch or fix to the affected systems and users.  A bug tracking system can help all customers and users of your software become aware of the bug and sometimes the way to workaround a bug until a fix is applied.  It also can let your customers know that they just need to upgrade to your latest version to obtain the fix for the bug.  In addition, it helps you keep track of when and where you made the fix so that you can manage related issues with the fix, follow up issues, or just to reminder yourself that you already fixed this bug.

10. Use a System to Track Tasks and Features Being Developed

Software professionals understand that delivering quality software includes keeping track of a lot of details.  A system and place to keep track of all of the things that need to be done is very valuable.  Your system could be something as simple as a Trello board.  Ideally you will have a list of everything yet to be completed and everything yet to be done.  Most tasks boards use at least three columns: To Do, Doing, and Done.  Even when you think a task is done you may decide it is not really done if you have not written the documentation related to the feature, or altered your install package to include a dependency for the feature.  The system also helps you remember the status of items and share the status, or share the work to be done, with others.

11. Keep Customers Informed About the Progress of the Software Development

In most software development projects, frequent interaction with the end user, aka ‘the customer’ greatly increases the chance that the software you create meets their needs.  Frequent communication also helps you manage your customer’s expectations about when features will be delivered to them and how those features will behave.  Although the waterfall method of software development describes collecting all of the requirements up front, it is extremely rare that you really can gather all of the details as well as you can if you keep the customer involved as you develop and can show them the product as it evolves.  Professional software developers will not leave their customers in the dark for weeks or months before giving them an update about the progress of the software.

12. Keep third party software used updated regularly

Most developers rely on some third party software to decrease the time it takes to produce the software their clients want.  For web developers, this may include frameworks like Microsoft .Net, Angular, React, JQuery, and Java.  But security flaws and performance problems, and other bugs occasionally get discovered in these frameworks, therefore a software professional regularly updates to the latest version of the frameworks in order to obtain the security patches and fixes to improve the security and performance of the software they pass on to their client.

I recommend you keep a list of all the third party software used by your software and your software development processes, and that you review the list at least twice a year in order to update each dependency to the latest version.

13. Understand the security risks

Professional software developers understand that they generally have more knowledge of software development than the customers that have hired them to write code.  Thus they understand that writing secure code, code that can’t be easily abused by hackers, is their responsibility.  A software developer creating web applications probably needs to address more security risks than a developer writing embedded drivers for an IOT device, but each needs to assess the different ways the software is vulnerable to abuse and take steps to eliminate or mitigate those risks.

Although it may be impossible to guarantee that any software is immune to an attack, professional developers will take the time to learn and understand the vulnerabilities that could exist in their software, and then take the subsequent steps to reduce the risk that their software is vulnerable.  Protecting your software from security risks usually includes both static analysis tools and processes to reduce the introduction of security errors, but it primarily relies upon educating those writing the code.

OWASP (https://owasp.org) is a good resource for developers to learn about possible vulnerabilities and ways to mitigate those vulnerabilities.

14. Ensure Proper Compliance with Industry Standards such as PCI, HIPAA, SOX, and PII

Writing software that complies with industry regulations is also a responsibility of a software professional.  It is the responsibility of the customer asking for the software to tell the developer that they need the software to meet specific regulations such as HIPAA, GDPR, PCI, SOX, or PII.  But is the responsibility of the software professional to understand how those regulations affect the software and software development processes.  A customer may suggest to the developer what impact the regulation has on the code, but if you are a software professional, you will refer to the regulation directly and clarify your own interpretation of the document.

15. Educate Yourself Continuously 

Technology continually changes thus professionals will continually learn new tools, techniques, and software languages in order to improve their efficiency and write software that lasts longer.  Even developers that have been programming in the same language and environment for a decade may discover that there are new tools and processes that can help them write better code.  Perhaps need static code analysis tools can help you find bugs in your code, or perhaps you can learn to write better code by switching from a waterfall methodology to an Agile approach.  Developers writing Visual Basic 6 code may realize they can begin writing more modular code and use classes to facilitate a possible rewrite to Java that is coming, but is still years away.  If you aren’t occasionally doing some research to find ways to improve, I don’t think you can consider yourself to be a professional software developer.  (If you are reading this article, you probably are a professional or planning to be one!)

16. Invest in Your Development Tools

A good carpenter doesn’t use a cheap saw, and a good software developer doesn’t just use the cheapest tools and equipment.  Luckily for software developers, many really good tools are free to use.  Some tools do cost a little bit of money, but the productivity improvement gained by paying for them is often well worth the price.

Besides software tools, developers sitting at computers writing code day after day probably benefit from having good hardware.  A computer with a lot of RAM and a fast hard drive and Internet connection may spare you waiting minutes or even hours each day.  Multiple monitors, a comfortable keyboard, mouse, and chair can contribute to your ability to write code a little more effectively each day.  Take time to invest in the small things that can improve your productivity, even if it is just by a small amount.

17. Properly License Development Tools and Software

Customers expect people they hire to work ethically.  Well, perhaps unethical customers don’t expect ethical behavior or are willing to turn a blind eye, but if you declare yourself to be a professional software developer I believe you are also declaring that you do things ethically, and part of being ethical is paying for the resources you use to develop the software solution.  This means that you will pay the correct price and licensing fees for the tools you use for development.  It also means that you won’t use the free or community version of tools to develop professional solutions that clearly don’t qualify for the rules of use for that version of the development product.  Just as you are probably making a living writing software for your customers, those people and companies that created the tools you are using to enhance your productivity are trying to make a living by writing their software too.

18.  Write documentation about the software

Professionals write documentation about the software to assist future developers that may need to take over maintenance and enhancements of the code.  Sometimes, that future developer could be yourself.  System diagrams, flow diagrams, use case diagrams, and comments in code explaining the complicated bits all go a long way toward helping future developers maintain the software if you are not around to do so.

19.  Keep a journal of your activity

Professionals often keep notes of their activities during software development.  The notes can serve several purposes, but most often they benefit yourself.  Perhaps you record why you chose one approach over another.  Perhaps you list expected benefits or drawbacks of a decision.  Perhaps you keep track of how often you perform IT maintenance or how you fixed some problems.  You may keep track of interactions with others and a record of tasks and responsibilities.  Professionals also use these notes to help explain where they spent their time and to explain why development is behind schedule, for those times when that happens.

Summary

I wrote this for people that are new to software development, particularly those who have completed a program in writing software and hope to embark on a career as a professional.  Most of the items covered in the article are not covered by formal software education programs, but are an essential aspect of writing good quality software.  Individuals writing software for a living on their own probably want to implement all of these practices in order to give current and potential clients confidence in the quality and professionalism of their work.

Please let me know if you feel something important is missing from this list so that we may improve this article as a good reference for developers.

And please check back for a future article where I cover those practices that make a software development “team” a team of professionals.