Software development is complex, but its foundations are not mysterious.
By following proven practices and embracing first principles instead of constantly reinventing the wheel, software development becomes disciplined engineering.
At a high level, every software engineering challenge rests on three legs:
- Delivery – defining the direction toward the goal
- Tracking – ensuring progress can be adjusted in an unpredictable world
- Organization – enabling work to scale beyond the founding team
From these legs, Modelithe developed; it started as a philosophy shaped by decades of experience across multiple branches of the software industry. It was later refined into a low-overhead structured method supported by an easy-to-use tool designed to help companies grow from fast-moving startups into large organizations without unnecessary process overhead. At Modelithe, we took a Swedish word as our compass: “lagom” – not too much, not too little, but exactly the right amount.
Most companies try to apply some form of agile mindset, where Scrum, Kanban, or home-grown variants are common at the team level. But many also simultaneously try to enforce a waterfall milestone and gate model with handovers for either funding or responsibility reasons. In the midst of this, they try to manage growing software teams by adding increasingly complex project management and issue tracking tools.
Contrary to what many believe Scrum prescribes, software engineering is not about 100m sprints where you can keep your eyes on the prize during every step. It is not even a triathlon of fullstack developers. Software engineering is better described as a cross-country ultra-marathon for a team – a challenge to be overcome through grit and mutual cooperation. Unexpected obstacles will appear, temporarily blocking the view of the goal. Some can be removed, others need to be worked around. Some paths are more complex than initially believed. And every now and then, a small detour to restock on supplies, funding or mental energy is needed.
For a successful development journey, it all starts where it ends; The delivery of the result – the combined achievement of all people involved.
The philosophy behind Modelithe recognizes these challenges as the default conditions of delivery – and provide a structured way of progressively adding tools and methods no earlier than when really needed during the development journey to achieve the small company’s growth needed for solving challenges on a global scale.
Delivery
Few companies fail completely to deliver. Eventually, most companies deliver something. But it might be too late, never recovering the ROI spent in the ever-delayed project. Or even worse, delivering the wrong product because of a poor market analysis. Delivering in time to specification makes no sense when the specification is wrong to begin with.
Knowing what to deliver is – on the other hand – impossible to begin with. “Putting a man on the moon and bringing him safely home again” is a vision – not a requirement statement. Neither did the engineers at NASA know they would need to build a five-engine 3-stage rocket the height of the Eiffel Tower.
Nor did they know they’d eventually need to fit a square peg into a round hole using duct tape and plastic wrap.
All of those things were discovered during the process.
Because that is the essence of delivery; converting an abstract idea into a product or service that solves real-life problems through continuous re-evaluation of the idea. The initial requirements can never be set in stone. An organization waiting for the perfect specification will wait forever, as the world changes faster than the requirement analysts can document.
The development doesn’t start with the first source code file being written. The development starts the moment the first engineer looks at the map, saying “we are at this point, and we want to go to that point – let’s start walking in that direction”.
Using Modelithe, developers can focus on what they like; producing high-quality value by solving the customer’s challenges. Modelithe allows developers to focus on first principles; enjoying the development journey by breaking complex problems into tasks of manageable complexity. There is no concept of work to be done – only the completion of tasks needed to achieve the end goal – no matter how that is formulated in the company’s vision statements.
Tracking
However, even highly skilled developers do need tracking during the development journey. In fact, we learn to track ourselves, ever since we were born; celebrating everything from our birthdays, to recognizing our way home. Similarly, most people are capable of remembering 7 things to bring home from the convenience store. But navigating through the mazes of IKEA requires planning and tracking to avoid returning home only to realize the door handles for the wardrobe were forgotten.
The most low-overhead issue tracking method for a software company is a whiteboard and post-it notes.
Up to a limit, that is. Second best is an Excel sheet.
Even if it may feel as if every problem can be solved with either duct tape or Excel or not at all, neither are the perfect tool for every problem. But, only when tracking in an Excel-sheet no longer meets the needs of the organization without spending indefensible amount of effort on keeping it afloat, does it make sense to invest in a dedicated issue tracking tool to simplify tracking.
The key thing though; more is not better. Too many of the tools on the market try to be the jack-of-all-trades; They contain too many options, too many trackable variables, too much information, and requires too much training or customization. All to motivate the high per-seat cost, and the consultants required to tweak the tool so it can measure what management believes is the most interesting KPI for the moment.
For most small companies, such tool don’t need to be more advanced than an Excel sheet – it just need to do what Excel did without doing what made Excel a dead end. Because a fool with a tool is still a fool. The rocket scientists of the 50s couldn’t in their wildest dreams imagine the tools we currently have at our disposal. For them, paper binders were the tools needed to ensure every nut and bolt were manufactured and assembled according to specification.
Tracking also contains the biggest contradictions in development; Teams want clear requirements early on, while product management prefers to commit as late as possible. At the same time, product management want the teams to commit to delivery dates. Teams unfamiliar with the Agile Manifesto or Scrum Guide might dodge commitments with “we work agile, so we can’t commit,” misunderstanding what agility truly requires.
Teams want to break down the complexity to achievable tasks before committing to delivery dates, while project and line managers needs to juggle the triangle of time, scope and quality to choose the next path for the company to take.
Stuck between a rock and a hard place, tracking might seem like waste if neither the team nor product management knows where the end goal is.
Tracking is not a matter of ticking of work on a to-do list. The list in its entirety cannot possibly be fully known or understood at the start of development. Neither is it a matter of counting the money spent.
The tracking of the development journey serves one purpose, and one purpose only – to ensure we always return to the right direction, at the right pace, doing the right things in the right order, even when faced with unexpected obstacles and ever changing circumstances to enable delivery and market introduction at the right time.
To counteract these contradictions and needs, the Modelithe tool was developed to bridge the needs of agility with the needs of predictability. The underlying Modelithe philosophy is deeply rooted in the visionary Agile Manifesto while still embracing a pragmatic view on the non-technical elements of software engineering. While Modelithe mandates neither Scrum nor waterfall, it provides the tools needed for sustained growth from Excel sheets to Scrum via Kanban or any other agile-inspired method to advanced program management.
Organization
Advanced tracking without an organization makes little sense. Measuring requires thought, and delivery is not a one-person-show. Tracking without an intent to tweak only adds overhead and frustration.
But still, not even the most skilled team of engineers will deliver without first organizing the tasks at hand; It might seem as they don’t need to. Experienced engineers who have worked with each other for years have developed a gut feeling for how to divide the tasks among themselves in an efficient (or fun – hopefully both) way.
But running the company based on the intuition of ever so skilled engineers, only works up to a certain scale.
Few companies can afford to only hire mythical 10x engineers. There aren’t enough of them in the world, anyway – if they even exist.
Sooner or later, the entrepreneur runs out of time, being both CEO, CTO, CFO, CMO and every other C-title imaginable while simultaneously managing 10-20 employees. Eventually another manager must be hired, offloading managerial work – in reality splitting the workforce into two teams.
Hopefully, the lowered burden eventually leads to more sales, paying for not only maintenance of the first product, not only keeping pace with competitors in the market but even being able to hire more engineers to provide solutions to more of the potential customer’s issues.
With more engineers, more customers, more products also comes more coordination. Growth puts the pressure to optimize the organization, to minimize the lead-times and dependencies between the different teams, to simplify the number of coordination surfaces.
Oddly enough, many organizations seem to evolve into some form of pyramid-shaped organization, potentially with a matrix of line and project managers – or even higher dimensions of stakeholders such as sales, support, finance, marketing, HR cutting through the matrix.
As Conway’s Law famously suggests, all organizations tend to mirror the architecture of their product. However, few organizations remain static for longer than two years – either due to growth, decay, change in skill set, personnel turnaround, internal politics or whatnot. While the organization changes, the architecture does not – at least not at the same pace.
Not only that, the collective knowledge eventually dilute.
Sooner or later, the original 10x engineers will have left the company, leaving behind 30-50-100-200-500 or even 1000 colleagues who lack the complete overview. No one fully understands the system, and the teams work at different paces with different short-term goals due to conflicting priorities, resource abundance (or deficit) and even internal politics. The misalignments erode organizational efficiency.
Modelithe provides the framework needed to scale a company from the founder’s personal todo-list by progressively increasing the toolbox with new layers of transparency despite the abstractions. But project management is not needed until the development journey turns from a daily grind to a budgeted activity. Program management is introduced as the company needs to deliver several projects in parallel, each reaching its own gates and milestones independently of other projects. An employee can be part of multiple teams; both classic lines, but also project teams, product teams and virtual teams of any kind; But only as needed due to the size of the company.
No silver bullet
Software projects fail not because engineers lack skill, but because organizations fail to balance delivery, tracking, and organization at the right level of maturity.
Through the years, trends in engineering have come and gone. Some had larger impact than others; the essays in the classic The Mythical Man-Month are still surprisingly valid fifty years later — a sobering reminder that the core problems are human, not technical.
ISO 9001 and CMM dominated the 90s, offering rigorous, auditable process frameworks; they improved consistency in large organizations but collapsed under their own bureaucratic weight in smaller teams. The documentation overhead consumed more energy than the work itself.
Lean, originally developed on Toyota’s factory floors, promised to eliminate waste and maximize flow, but manufacturing a car has a deterministic bill of materials, while software requirements have a stubborn habit of changing mid-sprint. At about the same time, the Agile Manifesto and the rise of Scrum addressed exactly that reality, embracing change and shortening feedback loops.
Yet, Scrum’s success depends heavily on organizational culture and team discipline, and it scales poorly without significant ceremony reintroduced at the project level. Waterfall, the methodology everyone declared dead, never quite left; it remains the default mental model for fixed-scope contracts, regulatory environments, and anyone who has ever had to commit a delivery date to a customer twelve months in advance.
No tool vendor, process expert or €500/h organization consultant can – with honesty and pride – promise a silver bullet solution to all of these challenges. Each methodology was a reasonable answer to the specific dysfunction of its era. The problem is that organizations keep reaching for the newest one rather than diagnosing which dysfunction they actually have.
Choosing the wrong tool, the wrong process, at the wrong time in the organization’s growth journey can cause more harm than good.
Engineers and managers do not want to spend energy trying to work around tools and processes not suited for the development journey of growth.
Modelithe is designed for this reality.
Modelithe is a tool and a structured method based on decades of software engineering best practices, in combination with the Swedish concept of “lagom“; it is the reasonable set of tools for the different stages of the development journey. Low-overhead enough for a high-velocity startup while sufficiently scalable for the global enterprise of the future, Modelithe provides the three legs of the stool comprising the key elements of software engineering; delivery, tracking, and organization. In alignment with the philosophy, the Modelithe tool runs on all three platforms: Mobile-first, Web and native PC.
Are you and your team ready to embrace Modelithe to do what you enjoy best: cooperate to achieve world-class solutions to real-world challenges for a global impact?