2022-04-30

Rules of Meeks: #003 - "When in doubt about an estimate, multiply by three"

(image source: 995645 on Pixabay)



From The Rules of Meeks

#003 - "When in doubt about an estimate, multiply by three"


This is hard-won wisdom that has proven itself again, and again.

This rule originated with my own early experiences trying to estimate software development tasks for myself - and over time, I learned that it was pretty damn good heuristic for many of the developers that I managed (at least until they established a higher level of reliability).

9 times out of 10, when you ask someone for an estimate - if they are honest, dilligent, and have confidence in their skill - they will be naturally optimistic. However, in my experience, most managers (and, engineers/developers) do not adequately include sufficient contingency (if at all) in their plans for the following:

  • Delays due to legal review, compliance review, contract negotiations, funding approval processes
  • Late discovery of requirements
  • Effort to do a minimally proper level of design
  • Effort to coordinate (and schedule!) the necessary communications and reviews of a proposed design approach - for complex projects that involve building something new - that involve multiple parts of an organization.
  • Effort to ensure that the Security parts of the org are involved and have reviewed the proposed solution
  • Effort to ensure that Legal has been involved and has reviewed the proposed solution
  • Effort to ensure that business stakeholders are adequately engaged, informed - and have buy-in
  • Effort to prepare Test Data
  • Effort to think through - and document Test Scenarios
  • Effort to develop and debug Test Scenarios
  • Effort to develop and execute Performance Tests
  • Effort to debug/fix issues that usually arise during System Testing
  • Effort to prepare (and test!) deployment procedures
  • Effort to write and document the solution's design, deployment, operational aspects, and just-enough documentation to communicate with other dependent teams/orgs
  • Effort to perform the inevitable rework that arises when designing something new for the first time
  • Unplanned meetings/interruptions - team productivity hits when folks have to attend meetings, training, the inevitable sick days - and accounting for slowdowns around holidays

This rule has also proven to be true when dealing with boat yards that have been tasked with maintenance/repair jobs on my sailboat. Usually, the factor is closer to 5x in that case.

2022-04-15

2022-04-15 Friday - Software Architecture is More Than Just Decisions

(image source: JillWellington on pixabay.com)


This post is intended as a response to a recent InfoQ article: Software Architecture: It Might Not Be What You Think It Is  [and this LinkedIn post]. These four statements from the article will give you some insight into what prompted me to write my response:

  • "Software architecture needs to be wrested from committees of people disconnected from developing, and to put it in the hands of the people who can actually make it real and executable, the developers."
  • "Software architecture is about capturing decisions, not describing structure"
  • "Architecting is a skill that agile teams embody, which means that Architect should not be a role"
  • "Software architecture has a contentious reputation in the agile community. In the experiences of many, it is the cause of valueless meetings and irrelevant documentation that is aptly summarized by the expression “the map is not the territory.” [underline and red coloring, my emphasis]

The level of formalism that any organization may invest in the practice of architecture - and the types of architect roles - and structure of architecture staffing - will of course vary, depending on several factors, such as: size of the organization, regulatory/compliance complexity, revenue, profitability, whether it is a start-up - or a large corporation. However, to dismiss the formal role of any architect - and apparently, the value of any formal architecture governance and oversight processes (outside of the delivery team) - is what I find particularly disturbing about the author's premise. 

A delivery team is necessarily primarily focused on the decisions within the locus of their control, their scope, their budget, their backlog, and their specific concerns.

There is a level of concern above the delivery team - and above the system-specific context - and that is where the broader enterprise-wide considerations exist. At this level, there needs to be the {freedom, latitude, ability} to take a longer and broader view - not driven, or limited - by the constraints of a delivery team's immediate goals, release cycles, or the narrower focus of a given project's budget/scope.

This is where the role of architect is certainly appropriate - to establish patterns, establish consistent and repeatable enterprise-wide governance, security, compliance, information architecture, define {principles, policies, standards, and specifications} - help establish long-term roadmaps, monitor and plan for rationalization, anticipate and plan for End-of-Life - and modernization transitions, and consider the dependencies across many systems (both internal - and external).

If your focus/concern is only about decisions focused on shipping/releasing a particular system - you lose the luxury (and time) to take the broader view - to consider the longer-term implications of decisions.

Quite often, the implications of a design can be anticipated by judicious investment in the creation/elaboration of architecture views - and conducting design reviews - before building, before shipping - which can hep mitigate security risks, compliance concerns, performance issues that can be identified by recognizing the anti-patterns inherent in a design, waste, rework, and identify opportunities for reuse across the enterprise.

When teams are measured/rewarded - according to their system-focused view - there is little incentive to consider the broader implications of design decisions at the enterprise level.

Architecture isn't just about design decisions for a single system - it is also about compliance, governance, communication, roadmaps, alignment, oversight for portfolios of applications - that may cross enterprises, and across organizational silos within an enterprise, and multiple project/delivery teams.

Architecture, as a discipline in IT - is not some ephemeral responsibility that can be randomly distributed. There is a minimum threshold of knowledge, experience, and expertise - required to perform in the role of an architect. Not everyone on a delivery team has that level of experience. 

Furthermore, there is a significant ongoing investment of time, effort, and money - that a competent architect invests in learning their craft, and maintaining/expanding the mastery of their craft. Delivery team members just don't have the luxury of time, and latitude of focus - to maintain that level of architecture competence.

Finally, I offer you: Meeks Software Architecture Conjecture #1:

(in response to the author's dismissive disregard for describing the structure of an architecture...)

The source code may (or may not) be a full implementation of the desired capability needed by the business - but is more likely just an approximation (constrained by permitted time, allocated budget, and available skills/talent of the team involved). Therefore it should not be confused with the actual or desired (or envisioned) design - that may require multiple years to achieve - of which the current source code may only reflect a partial (and incomplete, or inaccurate) representation.

Copyright

© 2001-2021 International Technology Ventures, Inc., All Rights Reserved.