About 10 years ago, I worked on a large, multi team (multi-org really) project that was run using TOC (Theory Of Constraints). Put very very very simply, every team was told to give honest, buffer-less estimates for their primary work areas, and then a global project buffer was added as a factor of the sum of estimates.
At any point in time, we worked as if every single thing would line up perfectly, so upcoming milestone targets would often feel crazy or unlikely. But people being eager to please, and mostly unwillingness to be the one team blocking the entire project - meant that folks worked hard to meet some of these targets.
It was extremely hard. It was a bit stressful. It felt crazy at times. But it got done in half the time I would have initially expected such a complex project to take.
To me, the most impressive thing about it all was that the project leader drove us all quite hard but was super cool - he explained that he wanted everyone to be open and honest about blockers so they could be moved with the full force he was given, and that actually, his way of measuring project progress was the rate at which schedules slipped.
That's wild. I've always wanted to see what projects managed with all the leadership buying into ToC or Reinertsen's Principles of Product Development Flow would look like.
As an engineer I've experienced dumb deadlines, but I've equally seen wasteful decisions by engineers that are at best resume padding and often legitimately harmful to product and code quality ("let's make this a microservice" lol).
My favorite is when leadership wants something dumb or contrary to reality and engineering teams are happy to build it because they can use fancy technology. Then when the product is delivered late, a little buggy, and users don't actually use it anyway — everyone can shrug, point to someone else as at fault, then rinse and repeat the game. Incentivizing honesty is hard.
Every deadline can be met if employees are "eager to please" and will work unlimited overtime hours for free. What estimation theory you use doesn't really change that. The true challenge of project management is – can you set realistic deadlines and meet them assuming a normal workforce with normal priorities putting in the standard amount of effort towards the job.
Did you like the outcome and did it feel sustainable?
I'm so conditioned to providing buffered estimates, especially for highly-dependent systems, I would really struggle to not accidentally buffer. I'm generally invisibly factoring in organizational dependencies (e.g. Bob will need to stand up service X, but Aditya's approval of that will be subject ridiculous process Q that always takes two weeks). It sounds like this would invert the dependency tree if broken down well enough.
Cynically, I struggle to imagine working in such a high-trust environment that wouldn't immediately be destroyed.
What does an honest, buffer-less estimate mean? Is it the number of person-hours to make you 50 % sure the task is completed? Or 90 %? Or something else?
Sure, you can do this for a couple weeks. Do this as the normal way of working and you'll end up alone. Burnout is a thing despite we agree or not on the reasons.
> But people being eager to please, and mostly unwillingness to be the one team blocking the entire project - meant that folks worked hard to meet some of these targets. It was extremely hard. It was a bit stressful. It felt crazy at times. But it got done in half the time I would have initially expected such a complex project to take.
Some others have suggested that this might not be sustainable or lead to a sense of personal fulfillment and satisfaction to everyone. Even moreso, that might just accelerate burnout for some, which probably needs to be taken into account.
I remember single handedly shipping around 70 versions of the homepage for Apturi Covid (https://apturicovid.lv/#en), the Latvian contact tracing app, back when we thought that contact tracing would be a viable way to limit the spread of COVID enough for it to die out. I did work a lot, it was a fast paced environment where around 100 professionals in the industry were allowed to collaborate to solve a problem to the best of our abilities and it indeed did result in a positive outcome at the end, the infrastructure, mobile apps and website all being developed in record time, working successfully up until this day and being handed off to the corresponding ministry with no problems.
Actually, i'm pretty sure that if the software were better (not even excellent, just good), a single server rack could probably maintain the entire system (failover aside) and serve the requests for the entire country, which has just 2 million people in it. Yet, it seems that they lacked the "secret sauce" that made our own project successful instead.
Of course, as someone who's single handedly leading an enterprise transformation and doing everything from modernizing enterprise apps in a project, to improving their security, migrating over to new tech, introducing containers, service meshes, APM, additional observability etc., i don't think that time pressure is always all that you're looking for.
After all, you want those that perform highly to be able to do so sustainably.
This article implies, but doesn't come right out and say, something that I strongly suspect: that producing an accurate (or even close-to accurate) software project estimate is a time-consuming, unpredictable task. The question nobody seems to be examining is whether or not the cost of doing a large, expensive up-front analysis that might take an arbitrary amount of time is less than the cost of just doing it concurrently with the software development itself.
I wish I could find the reference, one study showed that additional time spent estimating does not improve estimate accuracy. Only historical data regarding similar tasks were where estimates could be made accurately.
Example: How long will it take you to lean advanced physics? Even if I gave you a week, your estimate is likely worthless (maybe precise, but not accurate). To me this makes sense because you cannot know the unknown unknowns until you hit them (and throw in some of the journeyman fallacy)
Meanwhile, how long will it take to brush your teeth is easy to estimate. How long will it take to brush your teeth with a new electric toothbrush is also reasonable to estimate.
A lot of these articles assume the work being estimated will remain relevant during the estimated timeframe. My last (very large, not FAANG) employer started every project with a hard deadline, estimates were only used for budgeting not time, and then every project changed on a daily basis until it was obvious it would never ship by the deadline which was changed at the last minute. Every single project worked like this (note these projects were for us not external clients). I know of no theory of estimation that can account for continuous change unknown at the start.
Oh, people are examining that question alright. It's just complicated and therefore hard to come up with a definitive answer.
If I had to summarise what I have read on the topic, it would be that either way works, but the up-front analysis is orders of magnitude more expensive. Some sectors require this: defense, nuclear, medical, and so on. In most areas, you don't need that and can't afford it in a competitive market.
But to hint at the complexity of the question: Not only is every project different, there are also sneaky feedback loops in there.
By the time you have completed the large up-front analysis the world is likely to have moved underneath you, invalidating some of the assumptions that went into the analysis. You can shape your analysis to account for this, for sure. But at that point does it still count as one up-front analysis or several? Is it truly up-front if it leaves options and decision points open for later?
And it's a continuum: the more options and deferred decisions in the analysis, the more it starts to look like it's clearly done in parallel with the implementation. Where do we draw the line?
While this is likely true, the problem is W2 labor tends to be compensated on a more or less fixed price per unit of time basis, and to cover that cost, you need to bill clients roughly in proportion to total labor time spent, and most clients aren't going to purchase something for an unknown price to be named later. So you need to estimate to give them a price.
From the perspective of the seller, these estimates don't even need to be "accurate" as long as you're making many of them and the errors are symmetrically distributed. There's even math theory behind this called Fermi estimation. The problem is, from the client perspective, they can't average out the errors over many estimates if they're only buying one thing, and from the seller perspective, I don't think our errors are symmetrically distributed. Instead, we consistently underestimate how long something will take.
It's not even unique to software. There's a huge housing boom going on where I live, with condo developments all over the place, and not a single one is actually ready to open by the season their sign out front claims they'll be open. Defense acquisition. Highway construction. Everything takes longer than budget forecasts claim.
The problem is that once someone gives a date, then they are judged based on that date. In some cases, the software stops making financial sense after some multiplier of this initial date.
To avoid estimation you need to avoid dates and avoid projects that have high timeline risks. This means you would need to judge on speed to completion, or better customer satisfaction for project execution.
If think about estimate as learning activity in the sense of Theory Building, then you won't really care about the estimate by itself (which is a nice by-product) but as a confirm that the task is clear and actionable. In that the real value I think.
Isn't this basically scrum? Instead of doing an estimate at the start, you determine the throughput of the team and then give an estimate based on that measurement. That's my understanding of it anyway, could be wrong on that.
Treating every project as if it's in emergency mode is a great way to burnout the team and get shoddy work results.
Another idiotic practice is multitasking since context switching introduces tons of overhead.
And tying it all together, the importance of a project determines its resources. A truly critical task needs 100% focus. If a manager isn't willing to assign a full-time employee to a task, then that project isn't critical.
> The Yerkes–Dodson law refers to an inverted U-shaped relationship between performance and arousal, where performance increases with arousal, but only up to a certain point.
The quest to discover and apply "laws" like this courts disaster or disruption because people are neurodiverse. ADHD people respond to deadlines in a completely different way to non ADHD - sometimes inversely, sometimes obversely, and so require different management. Same but different with autistic spectrum people, introverts, extroverts, bipolar, insomnia, sleep apneates, diabetics and long covids.
It may be tempting to dismiss neurodiversity as a fringe consideration and just assume most people are "normal", but their circumstances, both in the workplace and beyond it, may complicate Yerkes-Dodson as much as neurodiversity whilst evading detection by managers and systems.
Well written and thorough article, but I can't help notice if this isn't just reverse engineering a standard MBA curriculum.
> Time pressure is also reported to be the most frequent external cause of unhappiness among developers.
> The inverted U-shaped relationship is one typical example of this, which means that time pressure increases efficiency up to a certain point, but after that increases in time pressure cause a decrease in efficiency
A good manager knows how to sustain just the right amount of pressure.
> [In this article, time pressure refers to both budget pressure, e.g., eight hours (budget) to do a task, and schedule pressure, e.g., a task that must be done by tomorrow.]
Aren't these the same thing? the latter being somewhere around 24hours give or take
I may want something to be done by the end of next week and at the same time I would like somebody to spend less than 4 hours on the task. Spending entire two weeks of effort would not be acceptable in this case even if the task was delivered on time.
An example would be a task that is not on the critical path of the project but still needs to be done. There is a deadline by which it must be delivered or it becomes part of critical path and starts delaying entire project.
Assuming the task is performed by one person using the fraction of the time available before the deadline, I would like to be able to use the rest of that time (resource) as either a buffer in the project or for completion of another task. Having the person deliver the task before deadline but after two weeks of continuous work where I assume only 4 hours will be necessary means that the project was deprived of almost two weeks of buffer or there are now some other uncompleted tasks.
When we are talking about project management, there is an important, clear distinction between time and cost.
Maybe this will be hugely impopular, but in addition to the three causes mentioned, isn't it possible that one cause actually comes from developers simply not performing?
If comparing to sports, in a team, is it always the coach's fault? Or is it possible that one player is not performing as expected? Is it then the coach's issue that he/she didn't expect that?
At the beginning of my current job (I joined as CTO) I had to inherit a lot of misunderstandings that the management team had.
They had hired people who knew nothing about building software (before me joining), most likely those people have never really built and shipped anything. Everyone on the management was under the impression that software is easy and everything needs to be delivered on time and if it's delayed we need to throw more money at the problem and that would solve the problem. They would continuously ask for "timelines" and never understood the word "estimate". They knew the definition of the word but could never accept the reality of the definition.
I was tasked with building a brand new core banking engine and a kyc engine. I talked to the existing tech team that was there and none had ever done anything complex. Mostly they just knew how to write some basic PHP pages to do some simple tasks like rendering a CSV table for a specific report etc... So they needed to first be trained.
To cut a long story short I was the only one on the team to be able to write productive code to build such a complex system. I hired someone who could write code to help train the existing team. However given the complexity of the problem and the tight timelines I had to solve. I basically did the design and implemented about 70% of the code myself while my other teammates were being trained. This also included building a KYC engine along the way. I remembered suffering immensely building the engine and hiring / building the team. I would focus on working with the team during the day and coded at night, since that was the only time I could get un-interrupted hours to code.
I worked til 2AM almost every night for 7 days a week for over a year (6 months to get it to launch and then refinements / continuous improvements after). To complete the engine and get it to serve hundreds of thousands of transactions every month. I was never paid for overtime. Today the company stands strong with handsome profits.
Trust me. I can tell you, the problem is not the developers / process / agile / kanban / etc..., the problem is management. It's always management. I was able to get management to understand the true scope of the task by stopping working overtime and standing my ground (when the company had recovered and was able to produce a stable income to support itself).
The overtime I did hid away all the 'complexities' and the 'debt', and prevented the company from learning. I basically ended up paying for the company's mismanagement / toxic culture with my time. Fortunately a lot of toxic people left the company, a growing company will generally push out the non-performers organically. It took a lot of effort on my part personally to resolve issues plaguing the company, establish an engineering culture, build a strong tech team that can withstand pressure and deliver continuously and can build on top of the framework I provided.
The lesson has always been. It's never the software team (at least never the team I manage) whom are not productive or doing their best. It has always been management / company culture / never truly understanding the scope / requirement enough to understand how huge of an undertaking a given project is. I can tell you without a doubt this article pretty much hit the nail on the head. I'm living proof and have the battle scars to prove it.
Now I tell management about time estimates as it is. "No fixed timeline, the team estimate, the team builds, it's done when it's done, live with it or fire me."
I've fortunately afford myself the position to be able to deliver the truth serum to management and they have no choice but to accept it. It didn't come cheap, I'm still scarred.
I agree with this wholeheartedly, as someone currently going through a similar experience.
Management is an incredibly complex job, especially in software engineering, and the fact that we "promote" senior developers to it as if being a good developer was the only requirement to being a good manager is part of the issue in my opinion.
I'm sorry you went through this, and I'm glad you were able to extract some good out of it.
> and if it's delayed we need to throw more money at the problem and that would solve the problem.
> I talked to the existing tech team that was there and none had ever done anything complex. Mostly they just knew how to write some basic PHP pages to do some simple tasks like rendering a CSV table for a specific report etc
Where was all this money going that they were throwing at these problems if they are hiring fairly low level staff like this?
Great that you managed to do it, I would have just walked away.
I have long learned such personal efforts are worthless, specially when the next firing round doesn't care about them, just a thanks for the fish and see you around pat in the back.
TL;DR, literally, I didn't bother to read the whole thing. Time pressure will never go away. It only takes common sense to realize that those who want something, i.e. are paying for it, want it as soon as possible. The difference from making physical things is the perception that software is soft: it seems to be infinitely malleable and all it takes is hand waving magic or sheer willpower to manifest it. This is of course the lie that those building software understand, and those that do not, will not.
[+] [-] int0x2e|4 years ago|reply
[+] [-] code_biologist|4 years ago|reply
As an engineer I've experienced dumb deadlines, but I've equally seen wasteful decisions by engineers that are at best resume padding and often legitimately harmful to product and code quality ("let's make this a microservice" lol).
My favorite is when leadership wants something dumb or contrary to reality and engineering teams are happy to build it because they can use fancy technology. Then when the product is delivered late, a little buggy, and users don't actually use it anyway — everyone can shrug, point to someone else as at fault, then rinse and repeat the game. Incentivizing honesty is hard.
[+] [-] paxys|4 years ago|reply
[+] [-] lumost|4 years ago|reply
[+] [-] EsotericAlgo|4 years ago|reply
I'm so conditioned to providing buffered estimates, especially for highly-dependent systems, I would really struggle to not accidentally buffer. I'm generally invisibly factoring in organizational dependencies (e.g. Bob will need to stand up service X, but Aditya's approval of that will be subject ridiculous process Q that always takes two weeks). It sounds like this would invert the dependency tree if broken down well enough.
Cynically, I struggle to imagine working in such a high-trust environment that wouldn't immediately be destroyed.
[+] [-] kqr|4 years ago|reply
[+] [-] midrus|4 years ago|reply
[+] [-] KronisLV|4 years ago|reply
Some others have suggested that this might not be sustainable or lead to a sense of personal fulfillment and satisfaction to everyone. Even moreso, that might just accelerate burnout for some, which probably needs to be taken into account.
I remember single handedly shipping around 70 versions of the homepage for Apturi Covid (https://apturicovid.lv/#en), the Latvian contact tracing app, back when we thought that contact tracing would be a viable way to limit the spread of COVID enough for it to die out. I did work a lot, it was a fast paced environment where around 100 professionals in the industry were allowed to collaborate to solve a problem to the best of our abilities and it indeed did result in a positive outcome at the end, the infrastructure, mobile apps and website all being developed in record time, working successfully up until this day and being handed off to the corresponding ministry with no problems.
In contrast, our national e-Health system has been in development for years, has cost around 14.5 million euros so far and still doesn't work: https://www-lsm-lv.translate.goog/raksts/zinas/latvija/par-e...
It's actually so bad that they're considering creating a new one to replace it, something that could have probably been avoided with enough care: https://www-lsm-lv.translate.goog/raksts/zinas/zinu-analize/...
Actually, i'm pretty sure that if the software were better (not even excellent, just good), a single server rack could probably maintain the entire system (failover aside) and serve the requests for the entire country, which has just 2 million people in it. Yet, it seems that they lacked the "secret sauce" that made our own project successful instead.
Of course, as someone who's single handedly leading an enterprise transformation and doing everything from modernizing enterprise apps in a project, to improving their security, migrating over to new tech, introducing containers, service meshes, APM, additional observability etc., i don't think that time pressure is always all that you're looking for.
After all, you want those that perform highly to be able to do so sustainably.
[+] [-] commandlinefan|4 years ago|reply
[+] [-] seadan83|4 years ago|reply
Example: How long will it take you to lean advanced physics? Even if I gave you a week, your estimate is likely worthless (maybe precise, but not accurate). To me this makes sense because you cannot know the unknown unknowns until you hit them (and throw in some of the journeyman fallacy)
Meanwhile, how long will it take to brush your teeth is easy to estimate. How long will it take to brush your teeth with a new electric toothbrush is also reasonable to estimate.
[+] [-] coldcode|4 years ago|reply
[+] [-] kqr|4 years ago|reply
If I had to summarise what I have read on the topic, it would be that either way works, but the up-front analysis is orders of magnitude more expensive. Some sectors require this: defense, nuclear, medical, and so on. In most areas, you don't need that and can't afford it in a competitive market.
But to hint at the complexity of the question: Not only is every project different, there are also sneaky feedback loops in there.
By the time you have completed the large up-front analysis the world is likely to have moved underneath you, invalidating some of the assumptions that went into the analysis. You can shape your analysis to account for this, for sure. But at that point does it still count as one up-front analysis or several? Is it truly up-front if it leaves options and decision points open for later?
And it's a continuum: the more options and deferred decisions in the analysis, the more it starts to look like it's clearly done in parallel with the implementation. Where do we draw the line?
[+] [-] nonameiguess|4 years ago|reply
From the perspective of the seller, these estimates don't even need to be "accurate" as long as you're making many of them and the errors are symmetrically distributed. There's even math theory behind this called Fermi estimation. The problem is, from the client perspective, they can't average out the errors over many estimates if they're only buying one thing, and from the seller perspective, I don't think our errors are symmetrically distributed. Instead, we consistently underestimate how long something will take.
It's not even unique to software. There's a huge housing boom going on where I live, with condo developments all over the place, and not a single one is actually ready to open by the season their sign out front claims they'll be open. Defense acquisition. Highway construction. Everything takes longer than budget forecasts claim.
[+] [-] lumost|4 years ago|reply
To avoid estimation you need to avoid dates and avoid projects that have high timeline risks. This means you would need to judge on speed to completion, or better customer satisfaction for project execution.
[+] [-] dilyevsky|4 years ago|reply
[+] [-] borracciaBlu|4 years ago|reply
[+] [-] gexla|4 years ago|reply
[+] [-] chrisaycock|4 years ago|reply
Another idiotic practice is multitasking since context switching introduces tons of overhead.
And tying it all together, the importance of a project determines its resources. A truly critical task needs 100% focus. If a manager isn't willing to assign a full-time employee to a task, then that project isn't critical.
[+] [-] wombatmobile|4 years ago|reply
The quest to discover and apply "laws" like this courts disaster or disruption because people are neurodiverse. ADHD people respond to deadlines in a completely different way to non ADHD - sometimes inversely, sometimes obversely, and so require different management. Same but different with autistic spectrum people, introverts, extroverts, bipolar, insomnia, sleep apneates, diabetics and long covids.
It may be tempting to dismiss neurodiversity as a fringe consideration and just assume most people are "normal", but their circumstances, both in the workplace and beyond it, may complicate Yerkes-Dodson as much as neurodiversity whilst evading detection by managers and systems.
[+] [-] disambiguation|4 years ago|reply
> Time pressure is also reported to be the most frequent external cause of unhappiness among developers.
> The inverted U-shaped relationship is one typical example of this, which means that time pressure increases efficiency up to a certain point, but after that increases in time pressure cause a decrease in efficiency
A good manager knows how to sustain just the right amount of pressure.
[+] [-] awb|4 years ago|reply
And they know about Parkinson’s Law: https://en.m.wikipedia.org/wiki/Parkinson%27s_law
> Parkinson's law is the adage that "work expands so as to fill the time available for its completion."
[+] [-] AnimalMuppet|4 years ago|reply
[+] [-] MaysonL|4 years ago|reply
[+] [-] e2e4|4 years ago|reply
[+] [-] quickthrower2|4 years ago|reply
[+] [-] rising-sky|4 years ago|reply
Aren't these the same thing? the latter being somewhere around 24hours give or take
[+] [-] lmilcin|4 years ago|reply
I may want something to be done by the end of next week and at the same time I would like somebody to spend less than 4 hours on the task. Spending entire two weeks of effort would not be acceptable in this case even if the task was delivered on time.
An example would be a task that is not on the critical path of the project but still needs to be done. There is a deadline by which it must be delivered or it becomes part of critical path and starts delaying entire project.
Assuming the task is performed by one person using the fraction of the time available before the deadline, I would like to be able to use the rest of that time (resource) as either a buffer in the project or for completion of another task. Having the person deliver the task before deadline but after two weeks of continuous work where I assume only 4 hours will be necessary means that the project was deprived of almost two weeks of buffer or there are now some other uncompleted tasks.
When we are talking about project management, there is an important, clear distinction between time and cost.
[+] [-] flerchin|4 years ago|reply
[+] [-] cjblomqvist|4 years ago|reply
If comparing to sports, in a team, is it always the coach's fault? Or is it possible that one player is not performing as expected? Is it then the coach's issue that he/she didn't expect that?
[+] [-] artellectual|4 years ago|reply
They had hired people who knew nothing about building software (before me joining), most likely those people have never really built and shipped anything. Everyone on the management was under the impression that software is easy and everything needs to be delivered on time and if it's delayed we need to throw more money at the problem and that would solve the problem. They would continuously ask for "timelines" and never understood the word "estimate". They knew the definition of the word but could never accept the reality of the definition.
I was tasked with building a brand new core banking engine and a kyc engine. I talked to the existing tech team that was there and none had ever done anything complex. Mostly they just knew how to write some basic PHP pages to do some simple tasks like rendering a CSV table for a specific report etc... So they needed to first be trained.
To cut a long story short I was the only one on the team to be able to write productive code to build such a complex system. I hired someone who could write code to help train the existing team. However given the complexity of the problem and the tight timelines I had to solve. I basically did the design and implemented about 70% of the code myself while my other teammates were being trained. This also included building a KYC engine along the way. I remembered suffering immensely building the engine and hiring / building the team. I would focus on working with the team during the day and coded at night, since that was the only time I could get un-interrupted hours to code.
I worked til 2AM almost every night for 7 days a week for over a year (6 months to get it to launch and then refinements / continuous improvements after). To complete the engine and get it to serve hundreds of thousands of transactions every month. I was never paid for overtime. Today the company stands strong with handsome profits.
Trust me. I can tell you, the problem is not the developers / process / agile / kanban / etc..., the problem is management. It's always management. I was able to get management to understand the true scope of the task by stopping working overtime and standing my ground (when the company had recovered and was able to produce a stable income to support itself).
The overtime I did hid away all the 'complexities' and the 'debt', and prevented the company from learning. I basically ended up paying for the company's mismanagement / toxic culture with my time. Fortunately a lot of toxic people left the company, a growing company will generally push out the non-performers organically. It took a lot of effort on my part personally to resolve issues plaguing the company, establish an engineering culture, build a strong tech team that can withstand pressure and deliver continuously and can build on top of the framework I provided.
The lesson has always been. It's never the software team (at least never the team I manage) whom are not productive or doing their best. It has always been management / company culture / never truly understanding the scope / requirement enough to understand how huge of an undertaking a given project is. I can tell you without a doubt this article pretty much hit the nail on the head. I'm living proof and have the battle scars to prove it.
Now I tell management about time estimates as it is. "No fixed timeline, the team estimate, the team builds, it's done when it's done, live with it or fire me."
I've fortunately afford myself the position to be able to deliver the truth serum to management and they have no choice but to accept it. It didn't come cheap, I'm still scarred.
[+] [-] Kaze404|4 years ago|reply
Management is an incredibly complex job, especially in software engineering, and the fact that we "promote" senior developers to it as if being a good developer was the only requirement to being a good manager is part of the issue in my opinion.
I'm sorry you went through this, and I'm glad you were able to extract some good out of it.
[+] [-] willcipriano|4 years ago|reply
> I talked to the existing tech team that was there and none had ever done anything complex. Mostly they just knew how to write some basic PHP pages to do some simple tasks like rendering a CSV table for a specific report etc
Where was all this money going that they were throwing at these problems if they are hiring fairly low level staff like this?
[+] [-] pjmlp|4 years ago|reply
I have long learned such personal efforts are worthless, specially when the next firing round doesn't care about them, just a thanks for the fish and see you around pat in the back.
[+] [-] edpichler|4 years ago|reply
[+] [-] f3rnando|4 years ago|reply
[+] [-] anonimamente|4 years ago|reply
[+] [-] bayesian_horse|4 years ago|reply