Chapter 7. - The Way of The Developer • Full Context Development

Our Role In The Organization —

Did you know that...

You as a developer can contribute meaningfully to the delivery roadmap?

You can offer information to the business about feature ideas they wouldn't find anywhere else?

There are important decision, determining the financial results of a product that only a developer can make with sound judgement?

In this chapter, I will show you how we are actually doing these, but in order to do so, I need to lay out the situation we are in when working as developers. This will show one of the most fundamental issues of the current practices. The fact that the full context of the software we are creating is hidden from us by the system itself. If you are experienced with the setup of a typical software development company feel free to skip ahead to the "Insights" part. The first step is to zoom in on the 2nd area of the software delivery landscape, the provider.

The life there follows 6 tracks, together these make up the software delivery lifecycle. Here is a short description of all the phases and their functions.

Business - the legal and financial entity and the organization, our colleagues (likely bosses) here create the business vision and strategy.

Management - the organizational work, setting up roles and responsibilities, schedule and budgeting, product and service details are planned and managed here.

Design - UI/UX including research - planning the look and feel of the product, detailing functionality and non-functional properties.

Development & QA - creation of the software.

Operations - deployment of software and maintenance of the systems.

Support - customer contact and issue resolution.

Doesn't matter the size of the organization, from the one-man-show to the multinational company, all of these phases are present during the development of any for-profit software solution, even if some of them are not formally defined, or mostly neglected. At the beginning of a long running project the tracks are executed sequentially, but the finished parts start to go in parallel with the rest of the work, until everything runs continuously. The key to identify the unique value we can provide is to understand the flow of information between the tracks. So let's examine it!

Business:

The information gathered on this level is about high level market trends, how to profit from them, what products or services they should create, the user needs, product market fit, the competition and so on. In essence, they set a goal called the vision and a high level plan to achieve it called the strategy. None of this information is guaranteed to lead to success, as life is too complex to fully understand all the relevant factors. The other major aspect is about the efficiency of the company's operation. On this level information coming in is about the market conditions. Information existing here is the insight the leaders and decision makers have about running a company in general and in the target business domains, also the information about the internal trends and state of the organization. The outgoing information are the vision and the high level strategy plans that usually include product or service ideas and roadmaps. These are passed down to management.

Management:

They organize and oversee the work from planning to execution. They are closely tied to the business. Often times involved in the work of that level, so their function is to translate the higher level goals to actionable items and to see them through. Parts of that work is outsourced to experts and leaders but coordinated by management. The expected functionality of software is formulated here to a certain extent. Schedules, deadlines, feature roadmaps are agreed upon at this level but these are also cross cutting concerns involving technical leaders. The information about the goals in its most complete form is given to the next stage.

Design:

Their task is to create the visual, interaction and any other relevant type of designs for the software. The goal is to form the product in ways that help to most effectively reach the defined business goals. That means driving user behavior towards the desired outcomes, such as generating more sales, viewing more ads etc. It's usually achieved by creating a pleasant and engaging user experience combined with the right marketing content and -of course- functionality. The information they have as input are the desired effects of using the software. For this they need to have a good understanding of the user needs. Some of that is coming from the above tracks but they usually have their own insight into these matters from their professional knowledge. Another source is the user research they do specifically for the project. At the end of this phase the created designs are handed out for implementation.

Development & QA:

In the planning stage, depending on the work methodology, the development leaders or whole development teams together with the people from above tracks might produce initial plans or detailed specifications for the solution and quality assurance tasks. Then the developers and testers create and validate the solution. The goal is to make it match the design and specification. The information input is in the form of schedules, system architecture designs, specifications, functional and non functional requirements. The information existing here is the knowledge about software engineering and testing in general and the technical knowledge about the current product line, environment and processes. Q&A usually have insight into the typical usage patterns of the applications and the most common issues faced by the users. The information going out are mostly reports about the relevant properties of the code and the development process for the management track. Product documentation and training materials might also be created fully or partially by the people on this track.

Maintenance:

Coming in information is about the software that needs to be deployed, updated or decommissioned. Infrastructure handling is also in the hands of this track, so information about upgrades, security patches, accident resolution and partial or total replacement of components is both incoming and already existing here. The other existing general information is related to the specific tools, practices and infrastructure in use. The outgoing information is mostly data about the system behaviors including statistics and error reports.

Support:

Or customer care, the people handling customer issues on the phone, chat, email, forums, social media etc. They have varying levels of knowledge about the inner workings of the systems. If engineers are providing support they have deep understanding, if it's dedicated personnel, they can be limited to usage and documentation level insight. Of course it can be anything in between these two ends. So the information present at this track is also greatly varying. However incoming information is mostly concerned with the necessary knowledge for the troubleshooting process, and expectations about the quality of service they provide. Outgoing information is usually issue escalation to the above tracks and statistics about their work.

Insights

This model is typical in many workplaces but it's far from being the only or the most effective way to execute software development projects. The roles and responsibilities are not always separated, there is collaboration between the different levels, people can wear many hats or be switching them but nonetheless the function of these tracks are present at most development companies. When it's implemented similarly to what I just described the problem mentioned at the beginning is visible. The business track doesn't propagate their goals to development directly. The design phase translates it into their output so their own concerns about the users and the desired business outcomes are presented to us encoded in the designs and requirements, without much emphasis on explicitly showing them. However this doesn't prevent us from having insights into the product that no one else has. What can we learn about our unique perspective from the position of development and the available information at that stage? First, stating the obvious, nobody else is deeply involved with the intricacies of the already existing systems regarding their code, architecture, non functional properties and inner workings. As experts of our field we are best suited to tell what's the optimal way to create the desired software. With most agile(ish), iterative development methodologies there's a back-and-forth between the tracks. On this kind of projects we regularly have a chance to redefine or bargain about the incoming requirements. When working in a more waterfall like situation we have less room for affecting the product vision but at the planning stages we still have a chance to make use of our insights. There are 10 major ways how we can do that:

We can tell which feature ideas are most feasible to implement with the given tools in the given environment. So we can rank them in order of delivery speed. That can be an important consideration when organizing the implementation schedule.

We can identify if there are technical blockers for a given request and give estimates of how long will it take to remove them. We can proactively raise awareness about these issues to get the delivery roadmap adjusted accordingly.

We can offer new technical solution and even new features based on our knowledge of the system's capabilities, the available data or other existing tools in the ecosystem, that the business doesn't even know about, that can better solve their problems. This can lead to suggesting alternative features that serve the same user needs.

We can judge if feature trade-offs can be made. For example to significantly lower the development time or costs in exchange for a minor functionality loss. This is possible because the 20/80 rule seems to apply to technical complexity vs delivered functionality in many situations.

We can adjust the development speed to prevent missing out important business opportunities by balancing the quality of code we create (aka "quick and dirty" solutions or "tech debt") and the number of features we deliver. Striking a balance and scheduling the payback is an art of its own and if the management is not well informed they can neglect this aspect which has led to many failed projects.

We can suggest alternative roadmaps if a different order of implementation makes the work more efficient. This usually means delivering a feature first that introduces a new technology replacing an old in-use tool so lowering the amount of code we need to rewrite later, or to batch tasks together that can utilize the same new technology, streamlining integration and refactoring efforts. There are situations when a planned feature is best implemented with a reusable component, if we know that's the case we can prioritize it before tasks that can utilize the created solution.

We can evaluate and estimate the costs and benefits of adopting different technologies to offer the best match for the company's financial and market situation. This involves choosing a preexisting tool but also evaluating the benefits of implementing a custom solution.

We can make informed judgements about optimization efforts, whether they are necessary and will pay off right now or in the future compared to being premature efforts that will waste the company's resources. This applies to application speed, scalability, fault tolerance, security and every other non functional property. This way we can suggest schedule alignments to handle these aspects.

Another part where we can take initiative, is process optimization. We experience first hand the pain points of the development workflow at the given company. We see where are the bottlenecks and we can alleviate many of them, given the chance. Including reassigning team responsibilities, matching mentors to different people, even changing team composition or reassigning the steps or dependencies of organizational processes, like technical decision making.

We know how to build codebases that are easy to maintain and extend, to make future development work more efficient so we can start initiatives to optimize these aspects, increasing development productivity on the long run this way.

Depending on the size of the company and levels of management present, you might be totally isolated from the business considerations of our work, or there might be nobody else who could take care of planning delivery. Either way, we have a unique insights about the systems that no other professions have and if we know how it's linked to business results we can deliver many additional benefits besides the requested software itself. I described all of the factors I'm aware of that nobody can come up with from a different discipline. Missing out on these is a huge loss for any company. This shows how collaboration in feature planning and delivery scheduling is a very important aspect. If you have been doing development for a couple of years this list might didn't surprise you, but keep in mind this is only what we can see from the flow of information in this model. These insights are purely based on what is presented to the development track and our technical knowledge. What if we can do things differently? What if more or different kinds of information would reach us?