The first kind says:<\/p>\n\n\n\n
\n“Yeah, I can probably get that done by Friday.”<\/p>\n<\/blockquote>\n\n\n\n
The second kind says:<\/p>\n\n\n\n
\n“Absolutely. No problem. I’ll have it done by tomorrow.”<\/p>\n<\/blockquote>\n\n\n\n
The first developer has learned from experience.<\/p>\n\n\n\n
The second developer has just joined the meeting.<\/p>\n\n\n\n
In software development, over-promising and under-delivering<\/strong> is practically a design pattern.<\/p>\n\n\n\n
We don’t put it in our architecture diagrams, but it’s there.<\/p>\n\n\n\n
Usually somewhere between the API layer and the database.<\/p>\n\n\n\n
\n\n\n\nIt Started With a Simple Requirement<\/h2>\n\n\n\n
Every software disaster begins with someone saying:<\/p>\n\n\n\n
\n“It’s a pretty small change.”<\/p>\n<\/blockquote>\n\n\n\n
There is no such thing as a small change.<\/p>\n\n\n\n
There is only a change whose complexity we haven’t discovered yet.<\/p>\n\n\n\n
“Just add a button.”<\/p>\n\n\n\n
Sure.<\/p>\n\n\n\n
The button needs to:<\/p>\n\n\n\n
\n
- Call an API.<\/li>\n\n\n\n
- Validate permissions.<\/li>\n\n\n\n
- Check business rules.<\/li>\n\n\n\n
- Update three tables.<\/li>\n\n\n\n
- Send an email.<\/li>\n\n\n\n
- Publish an event.<\/li>\n\n\n\n
- Update the audit log.<\/li>\n\n\n\n
- Work on mobile.<\/li>\n\n\n\n
- Work in Internet Explorer.<\/li>\n<\/ul>\n\n\n\n
Okay, maybe not Internet Explorer.<\/p>\n\n\n\n
But give it time.<\/p>\n\n\n\n
The developer looks at the ticket.<\/p>\n\n\n\n
\n“Yeah, probably a day.”<\/p>\n<\/blockquote>\n\n\n\n
This is the first promise.<\/p>\n\n\n\n
The universe has now started a stopwatch.<\/p>\n\n\n\n
\n\n\n\nThe .NET Developer’s Optimism<\/h2>\n\n\n\n
.NET developers have a particularly dangerous form of optimism.<\/p>\n\n\n\n
We look at a requirement and think:
public async Task DoTheThingAsync() { \/\/ TODO: Implement }<\/code><\/p>\n\n\n\nWe know exactly how to make an API endpoint.
[HttpPost] public async Task<IActionResult> DoTheThing() { return Ok(); }<\/code><\/p>\n\n\n\nFive minutes later, we feel unstoppable.<\/p>\n\n\n\n
The endpoint exists.<\/p>\n\n\n\n
The compiler is happy.<\/p>\n\n\n\n
Visual Studio has no red squiggly lines.<\/p>\n\n\n\n
The developer thinks:<\/p>\n\n\n\n
\n“This is basically done.”<\/p>\n<\/blockquote>\n\n\n\n
This is how it begins.<\/p>\n\n\n\n
\n\n\n\nThen Reality Arrives<\/h2>\n\n\n\n
The first problem is authentication.<\/p>\n\n\n\n
Easy.<\/p>\n\n\n\n
Except the endpoint needs a different permission.<\/p>\n\n\n\n
Then authorization.<\/p>\n\n\n\n
Easy.<\/p>\n\n\n\n
Except the permission system hasn’t been touched since 2018.<\/p>\n\n\n\n
Then validation.<\/p>\n\n\n\n
Easy.<\/p>\n\n\n\n
Except the business rules are documented in a Word document called:
Final_Final_Requirements_v7_REALLY_FINAL.docx<\/code><\/p>\n\n\n\nThen the database.<\/p>\n\n\n\n
Easy.<\/p>\n\n\n\n
Except the stored procedure has 2,700 lines.<\/p>\n\n\n\n
Then testing.<\/p>\n\n\n\n
Easy.<\/p>\n\n\n\n
Except nobody knows how the existing integration tests work.<\/p>\n\n\n\n
Then deployment.<\/p>\n\n\n\n
Easy.<\/p>\n\n\n\n
Except production has a configuration setting that doesn’t exist locally.<\/p>\n\n\n\n
Suddenly:
1 day estimate \u2193 3 days \u2193 1 week \u2193 \"We're almost there\" \u2193 \"Just fixing a few things\" \u2193 \"Can we move the deadline?\"<\/code><\/p>\n\n\n\n
\n\n\n\n“It’s Only a Small API”<\/h2>\n\n\n\n
This phrase has caused more suffering than most production outages.<\/p>\n\n\n\n
Someone asks:<\/p>\n\n\n\n
\n“Can you add an endpoint that returns customer orders?”<\/p>\n<\/blockquote>\n\n\n\n
You think:
[HttpGet(\"{customerId}\/orders\")] public async Task<IActionResult> GetOrders(int customerId) { return Ok(await _orderService.GetAsync(customerId)); }<\/code><\/p>\n\n\n\nSimple.<\/p>\n\n\n\n
Then someone asks:<\/p>\n\n\n\n
\n“Can we filter by date?”<\/p>\n<\/blockquote>\n\n\n\n
Sure.<\/p>\n\n\n\n
Then:<\/p>\n\n\n\n
\n“Can we filter by status?”<\/p>\n<\/blockquote>\n\n\n\n
Sure.<\/p>\n\n\n\n
Then:<\/p>\n\n\n\n
\n“Can we sort it?”<\/p>\n<\/blockquote>\n\n\n\n
Sure.<\/p>\n\n\n\n
Then:<\/p>\n\n\n\n
\n“Can we paginate it?”<\/p>\n<\/blockquote>\n\n\n\n
Sure.<\/p>\n\n\n\n
Then:<\/p>\n\n\n\n
\n“Can we export it to Excel?”<\/p>\n<\/blockquote>\n\n\n\n
Sure.<\/p>\n\n\n\n
Then:<\/p>\n\n\n\n
\n“Can the response be backwards compatible with the old endpoint?”<\/p>\n<\/blockquote>\n\n\n\n
Sure.<\/p>\n\n\n\n
Then:<\/p>\n\n\n\n
\n“Can we make it real-time?”<\/p>\n<\/blockquote>\n\n\n\n
At this point, the original endpoint has become a distributed systems problem.<\/p>\n\n\n\n
\n\n\n\nThe Meeting Estimate<\/h2>\n\n\n\n
There is a strange ritual in software development.<\/p>\n\n\n\n
Someone describes a feature.<\/p>\n\n\n\n
Everyone looks at you.<\/p>\n\n\n\n
You are expected to produce a number.<\/p>\n\n\n\n
Immediately.<\/p>\n\n\n\n
You have never seen the code.<\/p>\n\n\n\n
You don’t know the database.<\/p>\n\n\n\n
You don’t know the deployment process.<\/p>\n\n\n\n
You don’t know the dependencies.<\/p>\n\n\n\n
You don’t know whether the original developer is still with the company.<\/p>\n\n\n\n
But someone asks:<\/p>\n\n\n\n
\n“How long?”<\/p>\n<\/blockquote>\n\n\n\n
So you say:<\/p>\n\n\n\n
\n“Two days.”<\/p>\n<\/blockquote>\n\n\n\n
Why?<\/p>\n\n\n\n
Because saying:<\/p>\n\n\n\n
\n“I need to investigate the existing architecture, identify dependencies, understand the requirements, validate the data model, and then provide an estimate”<\/p>\n<\/blockquote>\n\n\n\n
doesn’t sound as productive.<\/p>\n\n\n\n
So you say two days.<\/p>\n\n\n\n
This is how software estimates are born.<\/p>\n\n\n\n
Not from engineering.<\/p>\n\n\n\n
From social pressure.<\/p>\n\n\n\n
\n\n\n\nThe Estimate Multiplier<\/h2>\n\n\n\n
Experienced developers eventually develop a secret formula.<\/p>\n\n\n\n
Someone says:<\/p>\n\n\n\n
\n“How long will this take?”<\/p>\n<\/blockquote>\n\n\n\n
Developer thinks:
Actual time \u00d7 3<\/code><\/p>\n\n\n\nManager hears:
2 days<\/code><\/p>\n\n\n\nDeveloper says:<\/p>\n\n\n\n
\n“Probably about a week.”<\/p>\n<\/blockquote>\n\n\n\n
Manager hears:<\/p>\n\n\n\n
\n“Two days.”<\/p>\n<\/blockquote>\n\n\n\n
Developer goes back to their desk.<\/p>\n\n\n\n
The manager tells the product owner:<\/p>\n\n\n\n
\n“We’ll have it by Wednesday.”<\/p>\n<\/blockquote>\n\n\n\n
The product owner tells the customer:<\/p>\n\n\n\n
\n“Definitely this week.”<\/p>\n<\/blockquote>\n\n\n\n
The customer tells their customers:<\/p>\n\n\n\n
\n“You’ll have it Friday.”<\/p>\n<\/blockquote>\n\n\n\n
Friday arrives.<\/p>\n\n\n\n
Nobody has it.<\/p>\n\n\n\n
\n\n\n\n“But You Said It Would Be Done”<\/h2>\n\n\n\n
Yes.<\/p>\n\n\n\n
I also once said I’d understand Kubernetes.<\/p>\n\n\n\n
We all make mistakes.<\/p>\n\n\n\n
The problem isn’t estimating incorrectly.<\/p>\n\n\n\n
The problem is pretending that uncertainty doesn’t exist.<\/p>\n\n\n\n
Software contains uncertainty everywhere.<\/p>\n\n\n\n
We don’t know:<\/p>\n\n\n\n
\n
- What we’ll discover in the existing code.<\/li>\n\n\n\n
- What requirements will change.<\/li>\n\n\n\n
- What bugs we’ll uncover.<\/li>\n\n\n\n
- What external dependencies will break.<\/li>\n\n\n\n
- What production configuration differs from development.<\/li>\n\n\n\n
- What the database will do under real traffic.<\/li>\n\n\n\n
- What security requirements someone forgot to mention.<\/li>\n<\/ul>\n\n\n\n
Yet we frequently give estimates as though we’re manufacturing identical screws in a factory.<\/p>\n\n\n\n
\n\n\n\nThe Developer Who Says “No Problem”<\/h2>\n\n\n\n
Be suspicious of the phrase:<\/p>\n\n\n\n
\n“No problem.”<\/p>\n<\/blockquote>\n\n\n\n
Especially when it’s said immediately.<\/p>\n\n\n\n
Experienced developers tend to say:<\/p>\n\n\n\n
\n“It depends.”<\/p>\n<\/blockquote>\n\n\n\n
This sounds less impressive.<\/p>\n\n\n\n
But “it depends” is often the beginning of an honest engineering conversation.<\/p>\n\n\n\n
For example:<\/p>\n\n\n\n
\n“Can we add this feature by Friday?”<\/p>\n<\/blockquote>\n\n\n\n
A responsible answer might be:<\/p>\n\n\n\n
\n“Probably, assuming the existing API supports it and we don’t need database changes. I’d like to spend a few hours investigating before committing.”<\/p>\n<\/blockquote>\n\n\n\n
A dangerous answer is:<\/p>\n\n\n\n
\n“Absolutely.”<\/p>\n<\/blockquote>\n\n\n\n
Because “absolutely” is just a future apology wearing a confident hat.<\/p>\n\n\n\n
\n\n\n\nAsync\/Await Has Given Us False Confidence<\/h2>\n\n\n\n
.NET developers have another problem.<\/p>\n\n\n\n
We can make almost anything look simple with:
await SomethingAsync();<\/code><\/p>\n\n\n\nLook at that.<\/p>\n\n\n\n
Beautiful.<\/p>\n\n\n\n
Asynchronous.<\/p>\n\n\n\n
Modern.<\/p>\n\n\n\n
Efficient.<\/p>\n\n\n\n
We have no idea what
SomethingAsync()<\/code> actually does.<\/p>\n\n\n\nIt could be:
await SomethingAsync() \u2193 HTTP request \u2193 Retry policy \u2193 OAuth token refresh \u2193 Third-party API \u2193 Database query \u2193 Stored procedure \u2193 Linked server \u2193 Another database<\/code><\/p>\n\n\n\nBut our code says:
await SomethingAsync();<\/code><\/p>\n\n\n\nSo obviously it’ll take approximately 14 milliseconds.<\/p>\n\n\n\n
Right?<\/p>\n\n\n\n
\n\n\n\nThe Magic of Dependency Injection<\/h2>\n\n\n\n
Dependency injection makes everything look beautifully organized.
public OrderService( IOrderRepository repository, IPaymentService paymentService, IEmailSender emailSender, IAuditService auditService, ILogger<OrderService> logger) { }<\/code><\/p>\n\n\n\nLook at that constructor.<\/p>\n\n\n\n
So clean.<\/p>\n\n\n\n
So maintainable.<\/p>\n\n\n\n
So enterprise.<\/p>\n\n\n\n
The developer confidently says:<\/p>\n\n\n\n
\n“The architecture is flexible.”<\/p>\n<\/blockquote>\n\n\n\n
Then they try to run the application.
Unable to resolve service for type 'IPaymentService' while attempting to activate 'OrderService'.<\/code><\/p>\n\n\n\nAh.<\/p>\n\n\n\n
The abstraction is working beautifully.<\/p>\n\n\n\n
Nothing has been delivered.<\/p>\n\n\n\n
\n\n\n\nThe Sprint Commitment<\/h2>\n\n\n\n
Sprint planning is where optimism reaches its highest level.<\/p>\n\n\n\n
The team looks at 40 tickets.<\/p>\n\n\n\n
Someone asks:<\/p>\n\n\n\n
\n“Can we get all of these done?”<\/p>\n<\/blockquote>\n\n\n\n
Developer:<\/p>\n\n\n\n
\n“If nothing unexpected happens.”<\/p>\n<\/blockquote>\n\n\n\n
Product owner:<\/p>\n\n\n\n
\n“Great!”<\/p>\n<\/blockquote>\n\n\n\n
Developer:<\/p>\n\n\n\n
\n“That’s not what I\u2014”<\/p>\n<\/blockquote>\n\n\n\n
Too late.<\/p>\n\n\n\n
It’s committed.<\/p>\n\n\n\n
Then someone takes vacation.<\/p>\n\n\n\n
Someone else gets pulled into production support.<\/p>\n\n\n\n
The CI pipeline breaks.<\/p>\n\n\n\n
A security vulnerability appears.<\/p>\n\n\n\n
The database migration fails.<\/p>\n\n\n\n
The product owner changes the requirement.<\/p>\n\n\n\n
And somehow the sprint is still considered unsuccessful because:<\/p>\n\n\n\n
\n“The team didn’t complete the committed work.”<\/p>\n<\/blockquote>\n\n\n\n
Yes.<\/p>\n\n\n\n
Because apparently the sprint was planned in a universe where software behaves predictably.<\/p>\n\n\n\n
\n\n\n\nThe Under-Deliver Part<\/h2>\n\n\n\n
Over-promising is only half the problem.<\/p>\n\n\n\n
The other half is what happens when we realize we can’t deliver.<\/p>\n\n\n\n
There are two approaches.<\/p>\n\n\n\n
Approach One<\/h3>\n\n\n\n
Disappear into the codebase.<\/p>\n\n\n\n
Stop replying to messages.<\/p>\n\n\n\n
Change your Slack status to:<\/p>\n\n\n\n
\n“Deep work.”<\/p>\n<\/blockquote>\n\n\n\n
This means:<\/p>\n\n\n\n
\n“I have no idea what’s happening.”<\/p>\n<\/blockquote>\n\n\n\n
Approach Two<\/h3>\n\n\n\n
Communicate early.<\/p>\n\n\n\n
Say:<\/p>\n\n\n\n
\n“I underestimated this. I found three dependencies that weren’t apparent initially. The original estimate is no longer realistic. Here’s what I can deliver by Friday, and here’s what needs additional time.”<\/p>\n<\/blockquote>\n\n\n\n
Approach Two is significantly less exciting.<\/p>\n\n\n\n
It is also considerably more professional.<\/p>\n\n\n\n
\n\n\n\nThe “Almost Done” Lie<\/h2>\n\n\n\n
Nothing in software is more dangerous than:<\/p>\n\n\n\n
\n“It’s almost done.”<\/p>\n<\/blockquote>\n\n\n\n
Almost done can mean anything.<\/p>\n\n\n\n
It can mean:
Code complete<\/code><\/p>\n\n\n\nOr:
Code complete Tests missing<\/code><\/p>\n\n\n\nOr:
Works locally<\/code><\/p>\n\n\n\nOr:
Works with my test data<\/code><\/p>\n\n\n\nOr:
Works if you don't click that button<\/code><\/p>\n\n\n\nOr:
Production deployment hasn't been attempted yet<\/code><\/p>\n\n\n\nIn reality, “done” should mean something closer to:
Implemented + Tested + Reviewed + Integrated + Deployable + Documented where necessary + Accepted<\/code><\/p>\n\n\n\nUnfortunately, “almost done” sounds much better in a status meeting.<\/p>\n\n\n\n
\n\n\n\nThe .NET Build Is Green, So We’re Done<\/h2>\n\n\n\n
We’ve all experienced this.<\/p>\n\n\n\n
The build succeeds.
Build succeeded. 0 Error(s) 0 Warning(s)<\/code><\/p>\n\n\n\nBeautiful.<\/p>\n\n\n\n
You deploy.<\/p>\n\n\n\n
Production immediately throws:
InvalidOperationException<\/code><\/p>\n\n\n\nBecause the build was successful.<\/p>\n\n\n\n
It never promised the application would work.<\/p>\n\n\n\n
It merely confirmed that the compiler had no objections.<\/p>\n\n\n\n
This is an important distinction in software engineering:<\/p>\n\n\n\n
\nCompilation is not correctness.<\/strong><\/p>\n<\/blockquote>\n\n\n\n
A green build is not a green production environment.<\/p>\n\n\n\n
\n\n\n\nTechnical Debt Loves Optimistic Developers<\/h2>\n\n\n\n
Every time we say:<\/p>\n\n\n\n
\n“We’ll fix it properly later.”<\/p>\n<\/blockquote>\n\n\n\n
technical debt quietly opens another account.
TODO: Refactor this<\/code><\/p>\n\n\n\nSix months later:
TODO: Refactor this<\/code><\/p>\n\n\n\nTwo years later:
TODO: Refactor this<\/code><\/p>\n\n\n\nThe developer who wrote it has left.<\/p>\n\n\n\n
The new developer asks:<\/p>\n\n\n\n
\n“Why is this like this?”<\/p>\n<\/blockquote>\n\n\n\n
Someone answers:<\/p>\n\n\n\n
\n“Legacy.”<\/p>\n<\/blockquote>\n\n\n\n
Legacy is often what we call our own decisions after we forget why we made them.<\/p>\n\n\n\n
\n\n\n\nHow to Stop Over-Promising<\/h2>\n\n\n\n
The solution isn’t to become the developer who always says:<\/p>\n\n\n\n
\n“No.”<\/p>\n<\/blockquote>\n\n\n\n
The solution is to become the developer who understands uncertainty.<\/p>\n\n\n\n
Instead of:<\/p>\n\n\n\n
\n“I’ll have it done Friday.”<\/p>\n<\/blockquote>\n\n\n\n
Try:<\/p>\n\n\n\n
\n“I expect to have it done Friday, assuming there aren’t significant changes to the existing implementation.”<\/p>\n<\/blockquote>\n\n\n\n
Instead of:<\/p>\n\n\n\n
\n“That’s easy.”<\/p>\n<\/blockquote>\n\n\n\n
Try:<\/p>\n\n\n\n
\n“The change looks straightforward, but I haven’t investigated the existing code yet.”<\/p>\n<\/blockquote>\n\n\n\n
Instead of:<\/p>\n\n\n\n
\n“Two days.”<\/p>\n<\/blockquote>\n\n\n\n
Try:<\/p>\n\n\n\n
\n“I estimate one to three days. I’ll know more after I investigate the database and existing API.”<\/p>\n<\/blockquote>\n\n\n\n
This isn’t weakness.<\/p>\n\n\n\n
It’s engineering.<\/p>\n\n\n\n
\n\n\n\nGive Estimates as Ranges<\/h2>\n\n\n\n
Software estimates often become more useful when expressed as ranges.<\/p>\n\n\n\n
Instead of:
3 days<\/code><\/p>\n\n\n\nsay:
2\u20134 days<\/code><\/p>\n\n\n\nAnd explain what drives the uncertainty.<\/p>\n\n\n\n
For example:
2 days: Implementation is straightforward. 4 days: Existing database logic requires changes or additional testing.<\/code><\/p>\n\n\n\nNow the estimate communicates information.<\/p>\n\n\n\n
The number isn’t pretending to be a prophecy.<\/p>\n\n\n\n
It’s describing uncertainty.<\/p>\n\n\n\n
\n\n\n\nUnder-Promise and Over-Deliver?<\/h2>\n\n\n\n
You’ve probably heard this advice:<\/p>\n\n\n\n
\n“Under-promise and over-deliver.”<\/p>\n<\/blockquote>\n\n\n\n
It sounds great.<\/p>\n\n\n\n
But there is a problem.<\/p>\n\n\n\n
If you consistently under-promise, you can also become the person who says:<\/p>\n\n\n\n
\n“This will take three weeks.”<\/p>\n<\/blockquote>\n\n\n\n
and delivers it in two days.<\/p>\n\n\n\n
Eventually management learns:<\/p>\n\n\n\n
\n“Their three-week estimates really mean two days.”<\/p>\n<\/blockquote>\n\n\n\n
Congratulations.<\/p>\n\n\n\n
You have created another estimation problem.<\/p>\n\n\n\n
The goal isn’t to manipulate expectations.<\/p>\n\n\n\n
The goal is accurate expectations<\/strong>.<\/p>\n\n\n\n
Don’t under-promise.<\/p>\n\n\n\n
Don’t over-promise.<\/p>\n\n\n\n
Communicate honestly about what you know and what you don’t know.<\/strong><\/p>\n\n\n\n
\n\n\n\nThe Most Valuable Developer in the Room<\/h2>\n\n\n\n
The most valuable developer isn’t necessarily the one who says:<\/p>\n\n\n\n
\n“I can build that.”<\/p>\n<\/blockquote>\n\n\n\n
It’s often the developer who says:<\/p>\n\n\n\n
\n“Before we commit to that date, there are a few things we should investigate.”<\/p>\n<\/blockquote>\n\n\n\n
That’s not being difficult.<\/p>\n\n\n\n
That’s preventing future disappointment.<\/p>\n\n\n\n
They ask:<\/p>\n\n\n\n
\n
- What does the existing system do?<\/li>\n\n\n\n
- What dependencies are involved?<\/li>\n\n\n\n
- What are the unknowns?<\/li>\n\n\n\n
- What can we deliver incrementally?<\/li>\n\n\n\n
- What could make the estimate wrong?<\/li>\n\n\n\n
- What is the minimum useful version?<\/li>\n\n\n\n
- What needs to be tested?<\/li>\n\n\n\n
- What happens when something fails?<\/li>\n<\/ul>\n\n\n\n
Those questions may slow down the meeting.<\/p>\n\n\n\n
They can also prevent a month of misery.<\/p>\n\n\n\n
\n\n\n\nSoftware Doesn’t Care About Your Deadline<\/h2>\n\n\n\n
This may be the hardest lesson.<\/p>\n\n\n\n
You can put:
Friday 5:00 PM<\/code><\/p>\n\n\n\non a project plan.<\/p>\n\n\n\n
The database doesn’t care.<\/p>\n\n\n\n
The compiler doesn’t care.<\/p>\n\n\n\n
The external API doesn’t care.<\/p>\n\n\n\n
The production environment definitely doesn’t care.<\/p>\n\n\n\n
Reality wins.<\/p>\n\n\n\n
The only thing we control is how honestly we communicate with the people depending on us.<\/p>\n\n\n\n
\n\n\n\nFinal Thoughts<\/h2>\n\n\n\n
Over-promising usually doesn’t start with dishonesty.<\/p>\n\n\n\n
It starts with optimism.<\/p>\n\n\n\n
We want to help.<\/p>\n\n\n\n
We want to look capable.<\/p>\n\n\n\n
We don’t want to disappoint people.<\/p>\n\n\n\n
We don’t want to be the developer who says:<\/p>\n\n\n\n
\n“I don’t know.”<\/p>\n<\/blockquote>\n\n\n\n
So we say:<\/p>\n\n\n\n
\n“Sure.”<\/p>\n<\/blockquote>\n\n\n\n
Then we discover that the “simple change” requires modifying an API, three services, two stored procedures, a database migration, an authentication policy, a background worker, and a configuration setting that only exists in production.<\/p>\n\n\n\n
Suddenly Friday looks very far away.<\/p>\n\n\n\n
The answer isn’t pessimism.<\/p>\n\n\n\n
It’s professionalism.<\/p>\n\n\n\n
It’s okay to say:<\/p>\n\n\n\n
\n“I don’t know yet.”<\/p>\n<\/blockquote>\n\n\n\n
It’s okay to say:<\/p>\n\n\n\n
\n“I need to investigate.”<\/p>\n<\/blockquote>\n\n\n\n
It’s okay to say:<\/p>\n\n\n\n
\n“That estimate has changed.”<\/p>\n<\/blockquote>\n\n\n\n
It’s okay to say:<\/p>\n\n\n\n
\n“We can deliver part of it by Friday, but the complete feature will take longer.”<\/p>\n<\/blockquote>\n\n\n\n
And yes, it’s even okay to say:<\/p>\n\n\n\n
\n“This is more complicated than we originally thought.”<\/p>\n<\/blockquote>\n\n\n\n
Because the goal of software development isn’t to make impressive promises.<\/p>\n\n\n\n
It’s to build software that actually works.<\/p>\n\n\n\n
Preferably before the customer starts asking where it is.<\/p>\n\n\n\n
And preferably without discovering that the entire feature depends on a 4,000-line stored procedure named:
usp_GetFinalFinalCustomerData_NEW2<\/code><\/p>\n\n\n\nPromise what you reasonably believe you can deliver.<\/strong><\/p>\n\n\n\n
Communicate when reality changes.<\/strong><\/p>\n\n\n\n
And never trust a requirement that begins with, “It should only take five minutes.”<\/strong><\/p>\n","protected":false},"excerpt":{"rendered":"
There are two kinds of developers. The first kind says: “Yeah, I can probably get that done by Friday.” The second kind says: “Absolutely. No problem. I’ll have it done by tomorrow.” The first developer has learned from experience. The second developer has just joined the meeting. In software development, over-promising and under-delivering is practically… Read More »Over promise and under deliver<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"neve_meta_sidebar":"","neve_meta_container":"","neve_meta_enable_content_width":"","neve_meta_content_width":0,"neve_meta_title_alignment":"","neve_meta_author_avatar":"","neve_post_elements_order":"","neve_meta_disable_header":"","neve_meta_disable_footer":"","neve_meta_disable_title":"","footnotes":""},"categories":[1],"tags":[],"_links":{"self":[{"href":"https:\/\/twobitranch.io\/index.php\/wp-json\/wp\/v2\/posts\/56"}],"collection":[{"href":"https:\/\/twobitranch.io\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/twobitranch.io\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/twobitranch.io\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/twobitranch.io\/index.php\/wp-json\/wp\/v2\/comments?post=56"}],"version-history":[{"count":2,"href":"https:\/\/twobitranch.io\/index.php\/wp-json\/wp\/v2\/posts\/56\/revisions"}],"predecessor-version":[{"id":67,"href":"https:\/\/twobitranch.io\/index.php\/wp-json\/wp\/v2\/posts\/56\/revisions\/67"}],"wp:attachment":[{"href":"https:\/\/twobitranch.io\/index.php\/wp-json\/wp\/v2\/media?parent=56"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/twobitranch.io\/index.php\/wp-json\/wp\/v2\/categories?post=56"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/twobitranch.io\/index.php\/wp-json\/wp\/v2\/tags?post=56"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}