00:00:01.800
Good morning. All right, so this is a photo of an interior reform that we did at home years ago.
00:00:08.240
As you can see, we demolished all the walls and rebuilt everything from scratch. These are complex projects; you have to decide everything from the room distribution to the interior design to the location of every single light switch and socket.
00:00:19.480
It's the kind of project that, as it progresses, you encounter setbacks. You have to rethink parts of the project, and also, as the project takes shape and you begin to visualize things, you realize that you may have to change your mind about certain details.
00:00:31.759
In this sense, it's not unlike software projects. In this particular project, I applied two valuable lessons that I learned from my experience in software development. The first one was to not provide the solutions but to explain the problem.
00:00:50.399
This translates into our approach for this particular project. We did not come with a fixed floor plan or anything like that. Instead, we explained to the agency how we like to live and the aesthetics that appeal to us because, ultimately, we are not the experts; they are.
00:01:05.520
They came back with proposals that we could never have thought of. Additionally, we surprised them by stating that we did not want a deadline. They were astonished because they said that every client typically insists on a deadline for renovations.
00:01:20.920
Our reasoning was simple: when issues arise during the project, we want everyone involved to focus on the result. We care about the outcome. We don't care whether this takes four months or five months; it doesn't matter. This is likely going to be our home for the rest of our lives, and that's what truly matters.
00:01:35.990
What mattered to us was that the project took as long as it needed to take, but it resulted in something we were going to like.
00:01:46.000
I have been working as a freelancer without deadlines for about 14 years; it will be 15 in June. This is how I work, and while this is a personal talk, I do not imply that everyone else should work this way or that they need to like this way of working.
00:01:56.720
This talk is about sharing my experience and my perspective on why I work this way.
00:02:10.640
To set the context for that, it's helpful to provide a little background about me. This was my first computer when I was a kid. I learned programming on my own by using a magazine. There was no internet back then, and this computer didn't even have a hard disk.
00:02:24.760
Hard disks were not a thing back then. It only had two floppy disks. I was a curious kid, learning how to program with that computer.
00:02:39.839
I ended up quitting high school when I was 16. I worked with my father, who had a small wholesale business dealing in pastries. A wholesaler acts as the intermediary between manufacturers and shops.
00:02:54.640
Sadly, they didn’t sell 'panita,' and I often think if they had, we could have certified yesterday either a Ferrari or a Porsche in our garage. But without panita, I also worked part-time at a music shop.
00:03:10.080
Eventually, I returned to high school at 21. Changing gears, as an older student, I discovered my passion for mathematics.
00:03:23.680
I was offered a position as a math teacher at the same academy where I attended high school. I took that position during the summer, and subsequently, I went to the math faculty in the center of Barcelona.
00:03:37.280
Those were amazing years spent studying math. During my degree, I also became a proofreader of math textbooks, which I did for six years for a publisher.
00:03:49.680
After completing my degree, I began working toward a PhD, but at 31, I decided to change gears again. I always had an interest in software, programming on the side over the years.
00:04:05.440
So I took my first job as a programmer at 31, at an agency primarily focused on Java projects. I was working full-time, but I also received a part-time lecturing position at the University of Barcelona.
00:04:20.720
For seven years, I balanced my full-time job with teaching, until our daughter was born and I had to quit teaching, as everything felt a bit overwhelming.
00:04:33.600
The next step after my first software job was to found a company specializing in Ruby on Rails, where I served as the CTO for three years, before becoming independent.
00:04:48.640
Since then, I have been working as a freelancer and consultant, starting in 2009, which has now been about 14 years.
00:05:04.160
As you can see, I do not have a typical computer science degree, but I do have a fair amount of experience in various projects.
00:05:16.560
It’s important to understand that not all tasks in software development are similar; for instance, creating a syllabus for a course is very different from transporting goods to a shop.
00:05:28.679
Some tasks are predictable, while others encompass uncertainty and unknowns. In my experience, I have found that working with dates is generally better suited for those predictable tasks.
00:05:40.760
At the core of my approach is software estimation. This topic isn't the main focus of my talk, but I believe that it relates closely to many of the issues we encounter.
00:05:56.799
I want to share a post from 2013, which I had to recover from the web archive. The post is both hilarious and spot on.
00:06:07.840
The title of this post was 'Software development estimates are regularly off by a factor of two or three times.' It serves as a metaphor, which I believe you will find amusing.
00:06:23.440
In the story, two friends in San Francisco decide to hike from San Francisco to Los Angeles, which they estimate will take about 400 miles.
00:06:40.480
They plan for specifics like their walking speed and hours per day, and they inform their friends they will arrive for dinner on Sunday.
00:06:56.000
However, upon commencing their journey the next day, they realize the route isn't as straightforward as they imagined. The map bears twists they hadn’t anticipated.
00:07:12.040
As a result, they adjust their estimate; it now seems they are going to need around 500 miles.
00:07:20.960
They then notify their friends that dinner will now take place on Tuesday, rather than Sunday, which they accept with some reluctance.
00:07:35.680
Shortly after, as they progress, they begin to encounter difficulties that none of them expected, like rocky terrain and changes in altitude.
00:07:50.800
They find themselves slowing down significantly due to the challenges, and blisters start appearing due to the distance and inadequate gear.
00:08:07.680
In the end, this means that rather than enjoying a simple hike, they must first go in search of supplies, losing significant amounts of time.
00:08:22.240
Moreover, each morning brings forth new obstacles, and they find themselves confronted with seemingly impossible routes.
00:08:32.320
They engage in passionate debates over whether to continue pursuing their goal, with one friend arguing that if they push themselves hard enough, they can still make it.
00:08:49.920
However, as days pass, they slowly realize that their estimates were far too optimistic—not only are they not crossing Bay Area but are still entrenched in its complexities.
00:09:07.760
This serves as an apt metaphor for challenges faced in software projects, where unknowns constantly surface—and flexibility is critical as you adapt and continue down the path.
00:09:19.800
As indicated earlier, I have worked in various companies using traditional methods, following strict estimation methods and deadlines.
00:09:29.320
Though I have stepped away from that, I still observe how it influences clients and their internal workflows.
00:09:38.160
My observations point to issues with date-centered workflows—an overarching term which indicates how our work is often constrained by deadlines.
00:09:47.680
One notable implication is that people often seem to work for the system.
00:09:53.280
Working for the system means that your focus is not entirely directed at tasks at hand; rather, energy is diverted to various ceremonies and meetings designed to please the established workflow.
00:10:03.760
In environments where fixed-length cadences are prevalent, such as sprints, it’s common to hear teams claim they work in two-week blocks.
00:10:16.239
However, in reality, tasks in software are rarely so easy to compartmentalize.
00:10:25.760
Therefore, planning is often fraught with friction, making the overall working environment less productive and more stressed.
00:10:36.440
Additionally, working toward deadlines can trigger psychological issues, as pressure builds to meet expectations.
00:10:48.519
When working with dates, associated vocabularies emerge: 'This project is on schedule', 'this task is late', etc. The desire to avoid being labeled as late can drive individuals to compromise on quality.
00:11:04.560
This can lead to a situation where people claim a task is complete, only for it to be half-finished or otherwise inadequate.
00:11:13.040
That mindset often creates an environment of shortcuts—neglecting refactoring or other necessary improvements in favor of merely checking off boxes.
00:11:21.320
This cycle can lead to residual technical debt that lingers in the repository, culminating in future roadblocks.
00:11:31.160
Ultimately, the most significant observation I want to make is that, usually, the due date is not what matters.
00:11:41.640
While some deadlines may be crucial, I find that when teams say they need something done within a specific timeframe, the 'why' behind that deadline is often unclear.
00:11:50.880
You should be asking yourself whether the specified timeframe genuinely adds value or if greater flexibility can yield improved results.
00:12:05.040
In my observations, I find that most of the time, those timelines do not substantiate themselves.
00:12:21.640
However, ongoing concerns regarding deadlines lead to distractions and nonessential overhead in how both you and your team operate.
00:12:32.160
Additionally, those distractions manifest in the development process, often leading to a lesser quality of output and implementation.
00:12:45.680
My experiences in freelancing have allowed me to explore how working methodologies without these typical constraints can yield far better results.
00:12:59.200
And over the past 14 years, this approach has worked well for me.
00:13:13.920
Let me summarize what I believe to be the essence of working without dates—it’s a mindset.
00:13:21.640
This is not a rigid procedure or technique; rather, it’s a mentality and a mode of thinking.
00:13:30.960
The first key aspect is maintaining a clear sense of priorities. Depending on the project, this could be through a prioritized backlog or focusing on a specific task within a larger project.
00:13:45.440
Continuous delivery is also a critical aspect, as it means that you are regularly shipping product updates.
00:13:59.920
In any context, whether literally pushing code to production or making technical decisions and assessing options, it’s vital to keep the momentum moving forward.
00:14:17.160
That focus keeps you engaged, as there’s nothing artificially interfering with your progress. Everyone on the team remains aligned, dedicated to the task at hand.
00:14:29.840
In my experience, this synchronization often yields higher quality results, as the solution typically goes through thorough scrutiny and testing.
00:14:43.760
Let me provide a specific example of a project I conducted along these lines.
00:14:56.360
A client needed to parameterize their application to enable multi-tenancy for different deployments across countries.
00:15:06.960
Essentially, instead of maintaining separate databases, they wanted to aggregate everything under a single deploy with a parameterized database.
00:15:16.440
My approach was never to ask the common trigger question, 'How long will this take?' Instead, I chose to focus directly on the tasks at hand.
00:15:29.480
The first step was to create a market table with two rows — one for the UK and one for Spain. This was an initial movement forward.
00:15:41.000
By doing so, we had already shifted one component into production, creating the impression that the project is progressing.
00:15:54.360
Then, understanding how each deploy identified their respective market became paramount. An environment variable was set up to facilitate this, alongside minimal adjustments in the codebase.
00:16:07.040
Following that, we systematically analyzed the models needing foreign keys and pushed those updates to production incrementally.
00:16:22.080
Each change provided the opportunity for adjustments, meaning we could progressively implement the solutions without disruption.
00:16:37.360
By the conclusion of the project, we effectively underwent a transformation while still conducting day-to-day operations.
00:16:51.680
There were no moments spent worrying about how we were tracking toward deadlines; our primary focus remained on executing the project accurately.
00:17:04.560
Now I want to address some objections frequently encountered regarding this method of working.
00:17:17.700
One common point is Parkinson's Law, which states that work expands to fill the time allocated for its completion. While that might bear statistical truth, I'm convinced there is more nuance.
00:17:29.760
With deadlines, there exists an inherent expectation that can lead to procrastination and unnecessary distractions. Without these rigid timelines, tasks may seem to extend indefinitely.
00:17:43.600
However, my personal experience and observational data, particularly from open-source endeavors, suggest otherwise.
00:17:57.040
In open-source communities, work generally progresses without strict deadlines or estimations. Even at conferences, it's rare to see people leave events due to impending deadlines.
00:18:10.440
The ongoing contributions of open-source communities demonstrate active engagement, continuously pushing code into the world without the constraints of set deadlines.
00:18:24.320
Another objection is that this approach is only viable for small companies or teams. However, I think there are notable exceptions.
00:18:39.520
For instance, Eric Beagern wrote an intriguing book and participated in internal discussions at Microsoft advocating for similar principles in their workflows.
00:18:54.360
Even in larger corporations, the core tenets of focusing on the work, rather than artificial constraints, remain highly applicable.
00:19:06.840
Of course, there will always be exceptions. For some individuals, deadlines can provide needed motivation.
00:19:21.520
If you know that a date serves as a catalyst for your progress, then by all means, use it. Some scenarios require hard deadlines—like regulatory changes—where they are genuinely unavoidable.
00:19:34.160
When those situations arise, ensure that the task associated with that deadline is treated as the highest priority. Organize your priorities accordingly.
00:19:49.440
Another strategy is to distinguish between core features to deliver and secondary, non-essential aspects of the project.
00:20:02.720
Focusing on delivering the core features ensures that essential elements remain unaffected, while 'nice-to-have' features can remain flexible.
00:20:16.280
After many years of implementing this approach, I have found it immensely satisfying from a professional point of view.
00:20:29.080
Not only does it allow you to engage in meaningful projects, but it also fosters an environment that emphasizes concentration.
00:20:42.480
Working this way avoids stress and elevates the experience to a state of flow, a healthy way to operate without constraints.
00:20:57.080
If you find yourself consistently wrapped up in the pressures of deadlines, I invite you to consider embracing this alternative perspective.
00:21:11.160
Thank you.
