What I've Learned About Development, After Years of Observing Programmers from the Sidelines

Years spent in business, especially in a field far removed from IT, taught me one important thing: between "I want" and "how to do it" lies a real chasm in the world of programming. I'm not a programmer by training – my path began with sports, painting, and then economics and landscape design. Nevertheless, from the early 90s, when I managed NPF Alkar and set tasks for programmers on management accounting, up to creating formspace.design at 61, I constantly encountered development. And here's what I've learned about it, observing from the sidelines.

The Chasm Between "I Want" and "How to Do It"

The very first, and perhaps most important, thing I realized is the fundamental difference in thinking. An entrepreneur, a practitioner, thinks in terms of tasks and solutions for the client: "We need the client to be able to select plants based on certain criteria," "I need a report on project profitability." A programmer, however, thinks in terms of code, algorithms, data structures, efficiency, and scalability. They don't see the end-user the way I do. For them, the task "select plants by criteria" breaks down into a database, filters, queries, interface elements, and so on. And often, the essence is lost in this translation. For example, I might say: "We need a CRM for a landscape business," implying tracking up to 20 simultaneous projects, with 20-30 parameters for each plant and a complex work cycle. A programmer, however, might start with a basic CRM suitable for any business, without delving into the specifics.

The Importance of a Clear Technical Specification (TS) and Why It's Always "Insufficient"

I've drafted technical specifications many times – first for management accounting systems at Alkar, then for process automation at Dom i Sad. And each time, it seemed I had detailed everything down to the smallest particular. But after the first iteration, I realized something was missing. Programmers don't read between the lines; they don't guess the context. If I didn't specify that when calculating the cost of paving a 50 m² plot with three types of tiles, 5% for waste and different laying prices for each type should be considered, then the calculation would be a simple multiplication of area by price. This isn't their fault; it's my responsibility as the client. I realized that why technical debt in business starts with a poor briefing is a direct consequence of an incomplete, albeit voluminous, TS. Every ambiguity is a potential error or delay.

The Programmer's Mindset: Not "What," But "How"

Programmers are engineers who build bridges out of code. They care about the strength of the structure, its efficiency, and speed. For me, as a business owner, it's more important that the bridge leads where it needs to and that people can cross it. This doesn't mean code quality isn't important, but priorities often diverge. A programmer might spend hours optimizing a query that runs in 0.01 seconds to make it run in 0.005 seconds, while for the business, it's more important that a new revenue-generating feature appears. This difference in focus is one of the key reasons why the difference between a product from programmers and a product from a practitioner is so significant. They see code; I see a solution to a client's problem.

Technical Debt and Its Roots in Communication

Technical debt isn't just "bad code." It's primarily the result of compromises made during development due to unclear requirements or a desire for quick results without proper planning. I recall a case where I urgently needed to implement a new calculation type to determine service profitability. The programmer created a "quick hack" that worked but was rigidly tied to one specific service. Six months later, when new services emerged and the calculation needed to be scaled, this "hack" turned into a huge problem requiring a complete overhaul. What would have taken a couple of days at the start with proper planning turned into weeks of work and thousands of dollars in costs. This is a typical example of how an unwillingness or inability to delve deeply into business logic at the outset leads to long-term problems.

How I Learned to Speak Their Language (or at Least Understand It)

Over the years, I realized that the only way to bridge this gap is to approach understanding the logic of development myself. This doesn't mean I became a professional programmer, but I started learning the basics, understanding system architecture, and grasping database principles. And with the advent of AI, at 61, I gained a tool that allowed me not just to set tasks, but to shape them, communicate with "code" directly, test my hypotheses, and even create prototypes. This gave me incredible freedom and the opportunity to build formspace.design without a staff of programmers. This is a path available to anyone willing to delve into the subject matter and demonstrate discipline.

When a Product is Needed "Here and Now," Not "When It's Finished"

Business cannot wait years for a perfect product. An MVP (Minimum Viable Product) is needed – a minimally viable product that solves the client's main problem, even if it's not perfect. Programmers often strive for perfection, flawless architecture, and the absence of bugs. This is commendable, but in the real world, it means missed opportunities and lost clients. My experience taught me to value speed and iteration. It's better to release a product with 80% of the truly needed functions and quickly refine it based on feedback, than to polish 100% of functions that might turn out to be unnecessary.

How My Experience is Reflected in formspace.design

All these years of observing and working with programmers, all my "pains" and "insights," formed the foundation of formspace.design. I created it as a tool that maximally smooths out these sharp edges. I aimed to make it intuitively understandable for landscape designers and property owners so they could realize their ideas without delving into technical complexities. The absence of a programming staff and the use of AI in development allowed me to create a product that reflects the real needs of the market, not just technical capabilities. It's a product I wished I had in my own practice.

How to Plan a Landscape in formspace.design

Imagine you want to create a recreation area with a pergola and a small pond on a 15-sotka plot. formspace.design is designed as a bridge between your idea and its realization, bypassing complex explanations with technical specialists. First, I would upload an aerial photograph or draw the plot's outline in module 1.0 "Plot Plan." This quickly provides a basis for work.

Then, using the zoning modules (1.1 "Zones"), I would define areas for a recreation zone, a children's playground, and a garden, considering cardinal directions and slope. In module 2.1 "AI Concept," you can get several design options by simply describing your wishes. For example, "modern style, minimalism, predominance of coniferous plants." The AI will suggest ideas that can then be detailed by adding objects (1.2 "Objects") – the same pergola, benches, lights. And module 3.1 "Design by Photo" will allow you to see how the selected elements will look on a real photo of your plot. This enables you to see the big picture and avoid many mistakes even before starting work, without resorting to expensive design services or lengthy explanations with contractors.

FAQ

Can I do without programmers if I have AI?

AI significantly simplifies the development process and allows non-programmers to create complex products, as I did with formspace.design. However, it's still difficult to completely do without understanding basic programming principles or external help during complex stages. AI is a powerful assistant, but not a replacement for deep knowledge.

What is the main difference in approach between business and IT?

Business is focused on the end result, solving client problems, and generating profit. IT specialists focus on the creation process, code quality, its efficiency, and scalability. The main difference lies in priorities: business values speed and functionality, IT values reliability and architectural purity.

How to avoid endless refinements and reworks?

The key to success is a maximally detailed and unambiguous technical specification, as well as an iterative approach with frequent feedback. Divide the project into small, verifiable stages (MVP) and test each function immediately after its implementation. This allows you to correct course before errors become critical.

Is it worth learning coding basics for better communication?

I believe so. You don't have to become a professional programmer, but understanding basic concepts (logic, data structures, API principles) will significantly improve your ability to set tasks and understand developers' responses. It's like learning a few phrases in a foreign language to better navigate a new country.

Why do programmers often not understand things that are "obvious" to business?

What seems "obvious" to business is often based on years of experience in a specific niche and implicit assumptions. A programmer, lacking such experience, cannot consider these assumptions "obvious." They work with what is explicitly written. Your task is to make the implicit explicit, by maximally detailing the context and business logic.

How to choose the right developer for your project?

Look for developers who show interest in your domain and ask many questions about business processes. Not only their technical stack is important, but also their capacity for empathy, their desire to understand why they are building the product. Be sure to check their portfolio and references, preferably with projects similar to yours.

My product is too niche, should I automate it?

Yes, niche products often benefit most from automation because standard solutions rarely fit them perfectly. Creating a specialized tool, even a small one, can provide a huge competitive advantage and significantly increase efficiency. It was precisely on such niche experience that formspace.design was built.

What is "technical debt" from a business perspective?

From a business perspective, technical debt refers to hidden costs that will arise in the future due to decisions made now to save time or resources. It's like taking out a loan: you get something now, but later you pay interest. These "interests" manifest as slowed development of new features, frequent errors, difficulty in scaling, and high product maintenance costs.

My journey to formspace.design has been long, full of mistakes and discoveries in communicating with the development world. But each of these understandings made me stronger and helped create a product that, I hope, will be useful to thousands of people. The main thing is not to be afraid to delve into what seems complex and always remember for whom and why you are creating your product. This is what true experience is.

Related Materials

• Read more