Speaker 1: Depending on which industry report you actually read, the global
Speaker 1: cost of failed software projects, howevers somewhere around the three
Speaker 1: trillion dollar mark annually.
Speaker 2: Which is just a staggering number.
Speaker 1: Right, it's massive, And if you've ever been adjacent to
Speaker 1: the tech sector, you know the anatomy of this disaster intimately,
Speaker 1: Oh absolutely, I mean, the project kicks off with this
Speaker 1: flawless vision, a rigid timeline, a highly specific budget, and
Speaker 1: then fast forward nine months, exactly, fast forward nine months,
Speaker 1: and the deadline is just a distant memory, the budget
Speaker 1: has somehow tripled, and the engineering team is completely burning
Speaker 1: out trying to ship like a deeply compromised product.
Speaker 2: Yeah, and it's so pervasive that corporate culture has essentially
Speaker 2: accepted it as a law of physics at this point, right, Like,
Speaker 2: the assumption is simply that software development is inherently unpredictable,
Speaker 2: so you know, budgets are just destined to blow up.
Speaker 1: But what if that unpredictability is actually an illusion? What
Speaker 1: if the root cause of these catastrophic failures happen before
Speaker 1: a single repository is even open. That's the real question, right,
Speaker 1: And what if it all comes down to a fundamental
Speaker 1: flaw in how we measure the work, because that is
Speaker 1: the mission of today's deep dive.
Speaker 2: Yes it is.
Speaker 1: We are analyzing a methodology that challenges the entire foundation
Speaker 1: of software project planning, which is the Functional Software Sized
Speaker 1: Measurement or FSSM.
Speaker 2: Yeah, and specifically we are looking at FSSM version one
Speaker 2: point zero. This is a really comprehensive system developed by
Speaker 2: jos Vier Singh and it was published in partnership with
Speaker 2: the IE Computer Society and Wiley, which are heavy hitters, definitely,
Speaker 2: And the core premise of this work is that we
Speaker 2: actually can accurately measure the true size and complexity of
Speaker 2: a software project right at the starting line.
Speaker 1: But there's a catch right right.
Speaker 2: Provided we abandon the industry's current favored shortcuts.
Speaker 1: Okay, let's unpack this because our source material today is
Speaker 1: frankly an incredibly dense, highly technical textbook.
Speaker 2: It really is. It's meant for software architects and project managers.
Speaker 1: Yeah, it's act with acronyms, formulas, deep structural theory. So
Speaker 1: our goal today is to extract the underlying mechanisms of
Speaker 1: this framework. We are going to figure out how FSSM
Speaker 1: actually operates under the hood without getting totally bogged down
Speaker 1: in the jargon. Sounds good, and we're going to figure
Speaker 1: out why the methods most companies currently use are basically
Speaker 1: setting them up for failure.
Speaker 2: Right, And to understand the solution, we really have to
Speaker 2: isolate the mechanical failure in the current standard first. Okay,
Speaker 2: makes sense, Like, if you want to know why projects
Speaker 2: budget explodes, you have to look at the tools they
Speaker 2: use to estimate its size in the first place.
Speaker 1: Right.
Speaker 2: The industry currently relies heavily on a few established methodologies
Speaker 2: for functional size measurement, with if POG and COSMIC being
Speaker 2: two of the most prominent ones.
Speaker 1: Yeah, I see those acronyms pop up and planning documentation
Speaker 1: all the time. But functionally, what are if PEG and
Speaker 1: COSMIC actually doing when they size up a project?
Speaker 2: Well, at their core, they measure size by focusing heavily
Speaker 2: on data boundaries and data mode movements. So IFPG, which
Speaker 2: stands for the International Function Point Users Group, evaluates logical
Speaker 2: data files and the transactions that cross the application's boundary,
Speaker 2: and COSMIC COSMIC is the Common Software Measurement International Consortium,
Speaker 2: and it similarly focuses on the movement of data, so entries, exits, reads,
Speaker 2: and writes, So they.
Speaker 1: Are essentially standing at the door of the software and
Speaker 1: counting how many pieces of data walk in and out,
Speaker 1: and like, how many filing cabinets are in the room.
Speaker 2: Yes, that is a highly accurate way to visualize it, right,
Speaker 2: And that creates a massive structural blind spot. How so,
Speaker 2: because by hyper focusing on data movement, they largely ignore
Speaker 2: the algorithmic complexity happening inside the room. Oh I see, yeah,
Speaker 2: They bypass the intricate details of user interfaces, the internal
Speaker 2: execution flows, complex air handling logic. They just measure a
Speaker 2: very limited subset of the software's actual functionality.
Speaker 1: But wait, if they're only measuring a fraction of the
Speaker 1: actual architectural work, how does a project manager use that
Speaker 1: output to generate a budget for the entire system? Because
Speaker 1: you can't just hand an incomplete measurement to the finance
Speaker 1: department and say fund this exactly.
Speaker 2: And this is where the methodology resorts to what Singh
Speaker 2: identifies as a critical flaw. Okay, the application of arbitrary
Speaker 2: multiplication factors. Because the measurement is incomplete, the planning framework
Speaker 2: attempts to compensate by taking that small, verified number of
Speaker 2: data movements and multiplying it by a generic factor to
Speaker 2: basically guess the size of the unmeasured work.
Speaker 1: Wow, okay, it sounds like trying to estimate the cost
Speaker 1: of building an entire custom house by only counting the windows.
Speaker 1: That's a perfect analogy, right, Like you look at the blueprint,
Speaker 1: you count ten windows, and then you apply some random
Speaker 1: generic house factor of five to guess the you need
Speaker 1: fifty units of wood in twenty units wiring exactly.
Speaker 2: And the structural danger of that approach is.
Speaker 1: Immense, because what if the house is a glass conservatory, right,
Speaker 1: or what if it's a subtrain and concrete bunker. The
Speaker 1: ratio of windows to structural materials change is completely based
Speaker 1: on the architecture. If you rely on a generic multiplier,
Speaker 1: you completely miss the complex plumbing, the specialized electrical grids,
Speaker 1: the foundation requirements. No wonder budgets explode.
Speaker 2: And that is the exact mechanism behind those blown software budgets.
Speaker 1: It's just wild to me.
Speaker 2: Yeah, The planning is built on a foundation of historical
Speaker 2: assumptions rather than the factual architecture of the current project.
Speaker 1: Which means they aren't really planning at all. Right.
Speaker 2: When companies use multiplier based estimations. They are not estimating,
Speaker 2: they are guessing. Yeah, because every software architecture is distinct,
Speaker 2: those generic multipliers inevitably fail to capture unique complexities, causing
Speaker 2: the timeline to slip and the budget to just evaporate.
Speaker 1: And for you listening, this is exactly why you should care.
Speaker 1: If your company relies on these multiplier based estimations. Your
Speaker 1: project planning is built on assumptions, not facts. So if
Speaker 1: guessing with historical multipliers is the mechanism of failure, then
Speaker 1: the FSSM methodology must provide a way to measure the
Speaker 1: entire architecture without relying on those shortcuts. So how does
Speaker 1: Jasvier Singh's framework actually measure the whole system? Well.
Speaker 2: FSSM, which by the way, operates in full compliance with
Speaker 2: the ISOIEES four two one three dot one Standards for.
Speaker 1: Software Measurement, right, which is important.
Speaker 2: It functions by measuring the complete actual functionality based solely
Speaker 2: on the project's foundational blueprint. Okay, it abandons historical statistical
Speaker 2: data entirely.
Speaker 1: Wait, let's pause on that Isostandard for a second, because
Speaker 1: usually when a textbook highlights an isostandard, it implies this
Speaker 1: massive checklist of compliance bureaucracy. Sure, what is the mechanical
Speaker 1: significance of fourteen one forty three to one in this
Speaker 1: specific context?
Speaker 2: That specific standard defines the fundamental concepts of functional size measurement.
Speaker 2: By adhering strictly to it, FSSM ensures that the size
Speaker 2: of the software is derived purely from its functional requirements.
Speaker 2: It prevents the methodology from drifting into arbitrary technical adjustments
Speaker 2: or environmental modifiers, so it keeps it honest, exactly. It
Speaker 2: forces the measurement to remain entirely.
Speaker 1: Objective, So it forces the measurement to stay grounded in
Speaker 1: the actual blueprint.
Speaker 2: Yes, the entire process begins with the Functional Requirement Specifications
Speaker 2: or the FRS.
Speaker 1: Okay FRS.
Speaker 2: FSSM parses this master document and categorizes the requirements into
Speaker 2: what it calls software's measurable components or smcs.
Speaker 1: Give me a breakdown of how it categorizes those components.
Speaker 1: What are we actually looking at?
Speaker 2: Well, FSSM segments the architecture into four primary pillars. You
Speaker 2: have functional data, functionality, execution, user interfaces, and message exchanges.
Speaker 1: Okay, those make sense.
Speaker 2: But identifying the pillars isn't enough. The methodology then drills
Speaker 2: down into the granular elements within each pillar, isolating the
Speaker 2: software component's measurable features or scmfs.
Speaker 1: Okay, I have to push back on the practicality of this,
Speaker 1: For it every single measurable feature in a massive enterprise application.
Speaker 1: That sounds like an administrative nightmare.
Speaker 2: It does sound intimidating, Yeah.
Speaker 1: Right, Like if a system has thousands of features, documenting
Speaker 1: and measuring each one individually before development even begins, doesn't
Speaker 1: that take forever? Isn't that the exact reason the industry
Speaker 1: adopted those multiplier shortcuts in the first place.
Speaker 2: Well, the perceived bottleneck is exactly why the industry relies
Speaker 2: on shortcuts. But FSSM addresses this by simplifying the actual
Speaker 2: measurement math.
Speaker 1: Oh really Yeah.
Speaker 2: While extracting the features requires analytical rigor, calculating their size
Speaker 2: does not require advanced calculus or complex algorithmic modeling. It
Speaker 2: relies on standard arithmetic addition, multiplication division, No advanced mathematics required.
Speaker 1: Okay, but how does basic math capture structural complexity?
Speaker 2: Because FSSM assigns a specific value known as a software
Speaker 2: component's feature point or SCFP to each granular feature.
Speaker 1: The future point.
Speaker 2: Okay, the calculation and evaluates the base data elements involved
Speaker 2: in a feature and cross references them against the complexity
Speaker 2: of the execution logic required to process them. I see,
Speaker 2: you calculate the points for the relational data, the points
Speaker 2: for the computational logic, the points for the user interfaces,
Speaker 2: and you literally just sum them up.
Speaker 1: So you are basically building a highly accurate cumulative point
Speaker 1: score feature by feature.
Speaker 2: Exactly. What's fascinating here is that while that upfront analysis
Speaker 2: does require a time investment, the return on that investment
Speaker 2: is the complete elimination of assumption errors. Right. Taking the
Speaker 2: time to properly index the structural components on the front
Speaker 2: end prevents the architectural surprises that cause nine month delays
Speaker 2: on the back end.
Speaker 1: Right, because it turns out that software components refuse to
Speaker 1: scale in predictable fixed mathematical proportions. No, they definitely don't.
Speaker 1: Here's where it gets really interesting, because the textbook provides
Speaker 1: some fascinating paradoxes to prove why we can't just rely
Speaker 1: on proportional scaling.
Speaker 2: Yeah, these examples perfectly illustrate the danger of abstracting away
Speaker 2: all those details.
Speaker 1: So let's look at the database paradox. If we use
Speaker 1: the older methods that just count operations, we run into
Speaker 1: a massive logical flaw. Imagine Application A requires fifty distinct
Speaker 1: data tables, but each table only requires a single memory
Speaker 1: read or write operation that gives us fifty total operations.
Speaker 2: Fifty operations. Got it?
Speaker 1: Now consider application B. It only requires two data tables,
Speaker 1: but the architecture demands twenty five read or write operations
Speaker 1: for each That also totals fifty operations.
Speaker 2: Right, and under a methodology that merely counts data movements,
Speaker 2: both applications receive the exact same functional size score.
Speaker 1: Which is just absurd from an engineering standpoint. Complete designing, normalizing,
Speaker 1: and mapping the relational integrity of fifty separate database tables
Speaker 1: requires a completely different tier of architectural planning, state management,
Speaker 1: and database expertise than setting up just two tables, even
Speaker 1: if those two are hit frequently. Right, the operation count
Speaker 1: is identical, but the actual structural effort is vastly different.
Speaker 2: And FSSM captures this discrepancy because it measures the data classes,
Speaker 2: the attributes, and the relational architecture. It doesn't just look
Speaker 2: at surface level read write transactions.
Speaker 1: Yeah, and the text highlights a similar issue with what
Speaker 1: they call the interface paradox. If an application has two
Speaker 1: user screens that are accessed fifty times in a specific
Speaker 1: workflow that generates one hundred input output operation, right, compare
Speaker 1: that to a system with one hundred unique user screens
Speaker 1: that are only accessed once. Again, one hundred operations either way.
Speaker 2: But the front end development overhead is entirely mismatched.
Speaker 1: Totally.
Speaker 2: Building one hundred distinct user interfaces involves massive UI and
Speaker 2: UX design, distinct state management for every single screen, and
Speaker 2: extensive component testing. Right, But two screens accessed frequently, that's
Speaker 2: just an exercise, and efficient routing multiplying operations completely obscures
Speaker 2: the actual labor required.
Speaker 1: And to scale this up to the macro level, the
Speaker 1: text compares the engineering of a telecon call handle application
Speaker 1: to a radar processing application.
Speaker 2: Right, And it's a vital comparison because it highlights how
Speaker 2: entirely different software domains allocate complexity. A telecom application is
Speaker 2: dominated by message communication and impute output routing. Okay, it
Speaker 2: constantly orchestrates signals between external modules, but it rarely requires
Speaker 2: heavy computational logic or deep memory manipulation.
Speaker 1: Whereas a radar application operates on completely different physical principles.
Speaker 1: It takes in raw signal data and runs intense filtering
Speaker 1: and extraction algorithms exactly. It is computationally heavy, but requires
Speaker 1: very little in terms of user interface or external messaging.
Speaker 2: And this is exactly why taking a generic complexity multiplier
Speaker 2: derived from the historical budget of a telecom project and
Speaker 2: applying it to a radar project results in a catastrophic failure.
Speaker 2: The foundational proportions of what makes each system complex are
Speaker 2: diametrically opposed. Right.
Speaker 1: It's like trying to measure the engineering requirements of a
Speaker 1: heavy duty agricultural tractor by using the standards of a
Speaker 1: commuter sedan.
Speaker 2: Oh, that's a great way to put it.
Speaker 1: They're both technically vehicles with wheels and an engine, but
Speaker 1: the core physics, the torque requirements, the structural stresses, they
Speaker 1: are completely different. If you use sedan multipliers to build
Speaker 1: a tractor, the machine will literally tear itself apart the
Speaker 1: moment you put.
Speaker 2: In the field exactly. And that analogy perfectly transitions us
Speaker 2: to the ultimate payoff of the FSSM methodology.
Speaker 1: Okay, let's get into the payoff once we.
Speaker 2: Have accurately measured the entire system feature by feature and
Speaker 2: generated an accurate cumulative score of software components feature points.
Speaker 2: We have to translate that data into a format that
Speaker 2: a business can actually use for resourcing.
Speaker 1: Right, Because an engineering manager can't just hand a developer
Speaker 1: a feature point, they have to allocate hours, days, and
Speaker 1: head account Right. So, how does FSSM bridge the gap
Speaker 1: between abstract points and actual time without falling back into
Speaker 1: the trap of those multipliers.
Speaker 2: Well, it utilizes a translation mechanism called Software size and
Speaker 2: Effort estimations.
Speaker 1: Or ses oka sees.
Speaker 2: Because FSSM has mapped the granular complexity of every component,
Speaker 2: it can establish a direct mathematical correlation between a specific
Speaker 2: feature point and standard engineering capacity.
Speaker 1: How does that correlation actually work mechanically?
Speaker 2: Instead of looking at how fast a previous team worked
Speaker 2: and assuming the new team will match it, FSSM evaluates
Speaker 2: the inherent complexity of the task itself. It takes the
Speaker 2: feature points and maps them directly to actual person days.
Speaker 2: Assuming a standard eight hour workday. It separates the effort
Speaker 2: allocations into distinct life cycle phases. Oh wow, Yeah, it
Speaker 2: calculates exactly how many standard person days are required for
Speaker 2: analysis for design, for coding, and for testing, completely independent
Speaker 2: of past statistical assumptions.
Speaker 1: So it standardizes the effort required for the architecture rather
Speaker 1: than guessing based on the unpredictable variables of the personnel.
Speaker 1: That provides a factual baseline for SIS scheduling exactly. But
Speaker 1: the methodology pushes even further than just development effort, doesn't
Speaker 1: it It separates static characteristics from dynamic characteristics. So what
Speaker 1: does this all mean for when the software is actually running?
Speaker 2: This is arguably the most powerful diagnostic tool within the framework.
Speaker 2: It introduces the concept of software performance quality Indicators spqis break.
Speaker 1: Down the distinction between static and dynamic measurement in this context.
Speaker 2: For me, sure, so, static measurement evaluates the code as
Speaker 2: it rests in their repository. It measures the architectural effort
Speaker 2: required to design and write the logic.
Speaker 1: Okay, so design effort right.
Speaker 2: The dynamic measurement evaluates how that architecture behaves when the
Speaker 2: system is actually executed and real time processing begins.
Speaker 1: The textbook uses this brilliant scenario to illustrate the danger
Speaker 1: of confusing.
Speaker 2: The two oh the loop scenario.
Speaker 1: Yes, consider a developer writing a single disc memory read
Speaker 1: operation from a static perspective, evaluating the design and coding effort,
Speaker 1: That is a highly trivial task. It registers as a
Speaker 1: minimal point of work.
Speaker 2: But the architecture dictates that the single memory read operation
Speaker 2: is placed inside an execution loop designed to trigger one
Speaker 2: thousand times every time a user initiates a specific workflow.
Speaker 1: Right and dynamically, that single line of code is no
Speaker 1: longer trivial at runtime. It generates massive memory traffic and saturates.
Speaker 2: The bus exactly.
Speaker 1: If the measurement methodology only looks at the static code structure,
Speaker 1: it categorizes the application as low effort and low impact.
Speaker 1: It completely fails to account for execution.
Speaker 2: Frequency, and that traditional method leaves the infrastructure team completely blind.
Speaker 2: They provision standard servers for a quote unquote simple application,
Speaker 2: and the system immediately bottlenecks at the database layer upon launch.
Speaker 1: Disastrous.
Speaker 2: But FSSM uses software operational indicators or sois to actively
Speaker 2: flag these dynamic stress points during the measurement phase.
Speaker 1: Let's look at another dynamic scenario from the text, involving
Speaker 1: decision trees. Okay, imagine a standard branch in the logic.
Speaker 1: If a condition is true, the application executes a series
Speaker 1: of heavy memory rights to update a massive data structure.
Speaker 1: If the condition is false, it simply routes the user
Speaker 1: to a static display screen statically.
Speaker 2: The architectural effort is split. The developer must design and
Speaker 2: code both the complex memory rights and the simple routing logic,
Speaker 2: so the static points reflect both paths right.
Speaker 1: But the business logic dictates that, based on real world
Speaker 1: user behavior, this decision branch will evaluate as true seventy
Speaker 1: five percent.
Speaker 2: Of the time, which means that seventy five percent of
Speaker 2: the time this module is executed, it is hammering the
Speaker 2: infrastructure with intense memory rights. A methodology that only measures
Speaker 2: the static code sees a balanced fifty to fifty logic fork,
Speaker 2: but fssm's software operational indicators evaluate the.
Speaker 1: Dynamic load, so they see it coming. Yes.
Speaker 2: They flag the fact that this specific decision node will
Speaker 2: heavily bias toward intense memory utilization, allowing the architects to
Speaker 2: provision memory caching or optimize the data base layer long
Speaker 2: before the code is even written.
Speaker 1: It's like putting the software architecture in a wind tunnel
Speaker 1: before you start manufacturing the parts. You aren't just weighing
Speaker 1: the static components. You are simulating the aerodynamic stress and
Speaker 1: fluid dynamics to see where the chassis is going to
Speaker 1: snap under pressure.
Speaker 2: That's a really good way to visualize it. The methodology
Speaker 2: moves beyond simple sizing and provides genuine diagnostic telemetry regarding
Speaker 2: the health, stress points, and performance requirements of the proposed architecture.
Speaker 1: This completely reframes how project planning should be handled. I mean,
Speaker 1: if we synthesize everything we've extracted from the text today,
Speaker 1: the primary takeaway for anyone managing, building, or fiancing a
Speaker 1: project is that relying on partial measurements and historical multipliers
Speaker 1: is a guaranteed recipe for disaster.
Speaker 2: Absolutely true, project stability can only be achieved through comprehensive measurement.
Speaker 2: The estimates must be derived directly from the functional requirements
Speaker 2: specifications cataloging the actual architecture feature by feature.
Speaker 1: By utilizing a framework like FSSM, you can translate those
Speaker 1: architectural realities into accurate eight hour person days for development
Speaker 1: while simultaneously predicting the dynamic run time performance of the system.
Speaker 1: And the immediate value for you as a listener navigating
Speaker 1: this space is that knowing this equips you to ask
Speaker 1: the exact right questions in your next planning meeting. Exactly
Speaker 1: when a timeline and a budget are presented, you can
Speaker 1: look at the architecture and ask, are we measuring the
Speaker 1: actual structural complexity of this system or are we just
Speaker 1: counting the windows and applying a generic multiplier?
Speaker 2: And if the answer involves historical multipliers, you know the
Speaker 2: underlying foundation is completely compromised.
Speaker 1: Yeah. Before we wrap up this deep dive, I want
Speaker 1: to leave you with a final thought provoking question for
Speaker 1: you to mull over that builds on the mechanisms we've
Speaker 1: discussed today.
Speaker 2: Okay, let's hear it.
Speaker 1: We've spent this entire session exploring how granular feature by
Speaker 1: feature measurement uncovers the hidden complexities and software architecture, proving
Speaker 1: that relying on generic multipliers destroys projects. But what if
Speaker 1: we applied that exact same logic to human organizational workflows?
Speaker 2: Wait, applying functional size measurement to corporate structure?
Speaker 1: Think about it. Consider the massive corporate restructurings that happen
Speaker 1: constantly and the fact that they so frequently fail to
Speaker 1: yield the promised efficiency. What if the reason corporate restructurings
Speaker 1: fail is the exact same reason software projects fail.
Speaker 2: Oh wow, right.
Speaker 1: Executive management often views fifty highly unique specialized employee roles
Speaker 1: simply as headcount. They apply a generic multiplier to determine
Speaker 1: how many people a manager can oversee, or how many
Speaker 1: tasks the department can handle.
Speaker 2: They're just counting boundaries, exactly.
Speaker 1: They measure the boundaries, the titles, and the salaries, but
Speaker 1: they completely ignore the algorithmic complexity of the employee's daily
Speaker 1: operational workflows.
Speaker 2: So they are managing the static org chart but ignoring
Speaker 2: the dynamic run time of the company itself.
Speaker 1: Exactly are we trying to architect our corporate structures by
Speaker 1: only counting the windows? Management refuses to measure the actual,
Speaker 1: granular functionality of their employees' daily operations. Perhaps a blown
Speaker 1: organizational budget is just as inevitable as a blown software budget.
Speaker 2: That is a really fascinating way to look at it.
Speaker 1: Definitely something to critically evaluate the next time a restructuring
Speaker 1: memo hits your inbox. Thanks for joining us on this
Speaker 1: deep dive.