In a nutshell, software engineering is a team driven practice that aims to build, design, develop, and maintain software. Having an effective process in place to maintain software over a period of time is a goal for any software engineer to strive for. As straight-forward as this concept is, this may easily become a challenging practice working within larger organizations. Especially as codes themselves becomes larger and more complex to manage and maintain. During a Tech Talk, Google software engineer Titus Winters was able to provide candid insight on constructing and maintaining software based on his experiences. In general, problems begin to arise when software begins to exceed timelines, exceed budgets, or when the software produces reduced levels of quality. Hence, Titus emphasized the importance in the consideration of three principles: Time, Scale, and Tradeoffs.
According to Titus, one of the first questions that should to be answered when starting software projects is “What’s the expected lifespan of the code?” Will the software be needed for only a few days, months, or perhaps decades? Titus explains, that shorter software projects (ones that require only a few hours or days) falls in the realm of programming projects in which little effort is required in terms of maintenance once the project is complete. Longer projects reside within the realm “software engineering” in which there needs to be more of a deliberate plan to design, develop, and maintain the software after its been completed. Longer lifespans are inherently difficult to plan for.
My interpretation is that understanding the projected lifespan of a software project can serve as the ground work in developing detailed and structured plans. These plans should emphasize requirements in maintenance or upgrade plans, amongst other things. This concept, or “the plan of the plan”, helps us set the expectation of work management from the start and also assists teams in meeting timelines throughout the project lifespan. Our goal to develop sustainable and resilient software. This may look different or have different criteria/resource requirements in considering varying lengths of project lifespan.
The next principle to consider is scalability. Software engineer teams need to be mindful of cost and scalability in terms of hardware, software, as well as human resources required for maintenance. Will our process exhaust all of the resources required for sustainability or will we be able to repeat our process as many times as necessary? Titus noted that, “In a successful organization, everything must be done repeatedly consuming sub-linear resources - especially sub-linear human effort and communication.”
The third principle, tradeoffs, spoke towards decision making. Throughout the project, decisions will need to be made about various ideas and approaches with various courses of actions. Teams faced with these decisions need to be mindful of making decisions based on evidence. These evidence-based decisions will keep teams “grounded” working towards realistic expectations. As software engineers, teams need to focus decisions cognizant that the decision will support sustainability of the project. Titus cautioned that evidence will change over time, so decisions will often need to be re-evaluated.
I agree and feel that I can relate to these concepts in terms of planning physical fitness training. Depending on the goal the training will need to be planned in a way that supports a sustainable process, lifestyle change, or habit to be successful. For example, training for an event, I would need to first understand and take into account the length of time I have to consider when creating my plans. I also take into account the workout equipment, gym availability, meals or other resources I will need (scale). Decisions I make on tailoring detailed workouts falls in line with tradeoffs i.e. will the workout sustain my fitness.
For me, this Tech Talk had reinforced the importance of understanding a problem or situation. Understanding in the sense that we need to know what we are trying to accomplish, how long we have to accomplish it, what can we use, and an end-state that the entire team aims for cohesively. For future software development project, I intend to always set time aside to deliberately plan, assess, and re-assess projects/decisions with these concepts in mind.
It’s programming if “clever” is a compliment It’s software engineering if “clever” is an accusation