Originally published on my blog.
//for those not familiar with ternary operator the title means:
if(isDeveloperUnderTimePressure()){
workFaster();
} else {
workBetter();
}
Mind reading and predicting future techniques aren't fully developed yet. So lots of software development projects are late. It get's better when the agile processes are successfully adapted but it's not always the case.
There's always more work to be done in the project than we initially predicted. Business needs change, we misunderstand the expectations, estimation errors can be also a case. There're lots of reasons something can go wrong.
"Improvement" ideas
Here're two common ideas supposed to help get your work done in time:
You put in more hours.
You compromise the quality of the product.
That's recipe for a disaster.
Overtime catch up
There might be some benefit in a few extra hours worked on Saturday to meet a Monday's deadline, but you'd want to catch up with your private life at some point.
Nobody can continually do creative intellectual work for over forty hours a week. Your effectiveness will decline sooner or later.
Compromise the quality of the product.
Imagine you have to implement new functionality. The manager stays over your head and tells you to work faster. Or tells you there are only 16 hours in a budget to implement the functionality.
Now, you can do it in a quick, but messy way or take your time to put in place a cleaner design. If you choose instant gratification in that step and implement the change quickly and not cleanly, you'll pay the price in the long run.
It's called technical debt. Technical debt is anything that should have been done as part of a development but wasn't. Those are unrefactored code, unresolved bugs, missing documentation, missed test cases etc.
Technical debt is like any other debt—you keep paying on it. Development time is getting longer. Implementation of new changes slows down because of debugging and hard to spot defects.
Don't cut corners. Improve.
Schedule pressure leads to cutting corners, overwork, and growing technical debt. This slowers delivery of valuable features.
Help to build awareness inside your team about those things and you'll see the great benefits in the future.
Latest comments (38)
There is an interesting dilemma I came across the other week. Do you use a technology you are familiar with or one you don't know but promises to make development time shorter? In other words, is a bigger but more accurate estimate better than a shorter but less accurate estimate? Given that you don't know what the accuracy is in the latter case it is hard to know.
Thank you for your poste , most managers try to deliver just to deliver, ignoring the after effect of the sacrifice of one of the fundamentals of software dev, Once you adopte the technical dept you will be stuck in an infinit loop that drag the dev team into all time pressure and frustration, in my case i am living in a test free application bubble.
I was asked recently to wire up a quick project and thinking the scope of the project was mostly going to be small and I was expected to get it ready by the end of the next day well I just wrote the code as fast as I could not thinking about patterns and structure. Fast forward a few days later and I've been asked to add a few more things to the project only now it's a big pain cause changing one thing requires me to make changes in a couple other places. Yes it's true that sometimes it's just enough to get it ready as soon as possible but in reality how often does this happen. Clients don't usually know what they want and make decisions about new requirements as the project progresses. So I agree that it's generally better to maintain the integrity of your code even though it might seem like a total waste at the time.
Could you please not use Dilbert as header photos? Adams is a miserable misogynist :-/
This week is the second time in two months that I quit due to the un-professionalism of the company. I miss to work (because I did) with truly professional companies.
It's important to interview the company as they are interviewing you before you decide to accept the job. Try to ask about their work culture and how they execute projects. How they deal with tight deadlines or what do they do when a project is late. Look for signs that discouraged you in previous workplaces and don't get hung up at a certain job just for the sake of having a job. It's important to work in the environment you can thrive and grow and help the company to get the best revenue possible in the process.
I want so much to work with people like you. Everything you wrote and I read, I'd like to have written it myself.
Thank you!
You should read The Mythical Man Month and Peopleware
"Nobody can continually do creative intellectual work for over forty hours a week. Your effectiveness will decline sooner or later."
I don't think so. I think this depends a) on motivation and b) on individual capabilities.
a) I know this from watching myself. If I work motivated on a project, I can work long days and enjoy the progress.
b) I know this from watching myself. When I was in my twenties I worked full time and studied and cared for my family. I did not feel tired all the time. Today, in my fourties, I feel tired in the evening and am happy to enjoy spare time activites. So if you mean by "Your effectiveness will decline sooner or later" "at least when you are fourty." then you may be right. But that does not mean that a twenty something should not work more than 40 hours if she is willing and capable.
I agree with you in both cases, but:
a) I also can work 50-60 hrs/week if I like the project. I even did 80. If I don't like it I still can, it just frustrates me in that case. But it's not about just doing the stuff. It's about how effective you are when time passes. If you are a good dev, even if you are not effective you still see the progress.
b) When I was at the University I could go on much longer, that's true. But then I also knew that I can play hooky if I needed and I had a vacation once a year and all those long breaks for Xmas and so on... How long you go on like this really depends on your fitness. But can you go on like this all year round? Sooner or later you'll need a break, a vacation, or just quit. If not, you are a superhuman (and I am sure my mum is, even though she's not a dev) ;)
I am so relieve that this is not a TDD cult advertising post..
I worked in startups in the last 8+ years, all we did was to deliver fast, cutting corners and do technical debt.
There are cases where these things are ok, you said "pay the price on the longrun". When you develop mostly prototypes, and MVP's and then you patch it up, and then you try something totally different and then you do A/B tests ... that future mostly never comes. I found out other situations (I will write soon a blog post) where if you plan ahead and do unit tests you actually lose time and it doesn't worth it.
Eventually some projects survive, and then the technical debt has it's revenge, but even then you would be amazed how ingenious managers/producers can be to avoid fixing it 😆.
Speaking of, I just wrote an article on how I managed to fix technical debt while continue delivering new features.
Also there are many cases where the Code Quality can be worst but the Product Quality remains untouched (from the user point of view).
Anyway I agree with your article, but the real world it's harsh and I have found that only a few product owners/producers/managers understand the quality of a good technical team and product, most of my peers haven't found any yet 😟.
Example: they will allow you now 10% of the time to save 60% of the future time to do things better.
Thanks!
I'm not advertising TDD. I just embrace clean code overall and teach my juniors the power of maintainable code ;)
And sometimes it's hard to implement TDD. Especially in legacy applications that weren't meant to be test driven ;)
And to have a good product you need a good team. A good team made of average developers can do more than the bad team made of superstars (I wrote about teamwork on my blog recently here: jumpstart.blog/2017/08/05/software... and here: jumpstart.blog/2017/10/05/a-bunch-...). And I know that word is harsh, but I keep fighting ;)
Thank you. Now I don't feel lonely.
Deadlines can be a big problem, specially when the person who gives estimations times doesn't know anything and they says "yes" to any clients whim
Excellent Article.
Thanks!
Scope, quality or budget... Typically, you can't have all 3 in a situations like that... While budget may be the easiest solution on a project, it may not really work. Adding people on late project make it later AND decrease quality... Except if you are lucky and have somebody available with all the context to help.
The real solution we all know it: to ensure projects are on time, margins are necessary. Don't over commit, include margin for issues/scope change etc. Because they happen all the time. Typically management doesn't like that because it decrease productivity. People work a bit less and the product may end up just on time. They even say it: adding more work, adding more tasks increase productivity, on way or another.
But ultimately, nobody can force you do work more or faster, to compromize quality. And nobody can force you to under estimate cost. The developper is much more in control that he may think.
As a side remark the 40hours a week is just a number. It depend of the person and activity. Some people can put 60 hours a week for years. For other this may be 20 hours. The rest of the time is not really used efficiantly. The person is tired and inneficiant.
Independently, individual hourly performance is also greatly different depending of the person or the task. So it is not always the person that work the most that product the most.
Finally, for quality, this is the same. Some people produce quality. Some other not. Often, behing late and the presure is just an escuse to reduce quality.
In all cases a good professional may have high, low or average productivity but will provide reasonable estimate, will do the job with the required quality and work at substainable peace, whatever it is for him/her. There may be late delivery, especially if people persist to not put margins and even sometime put artifical deadline or to reduce budget to put presure. But that's their responsability... When you have a bit of experience, you seen it all, the tricks do not work anymore.
Great post!
Thanks!
I'd say that one reason people end up under schedule pressure is because they are too optimistic in their estimations. Trying to estimate how long a task or a larger entity will take is just hard. Usually developers are good at estimating how long it will take to code something. However, usually there are also much more that needs to be taken into account: testing, delivery/deployment, documentation, unclear requirements, discussions with the customer and so on.
One way to improve is to track how good the estimates are and try to improve their accuracy over time.
As I said, we suck at predicting future.
It's not just estimations. Estimating is really a small part of it. We make incorrect assumptions about the requirements. Project scope changes. Someone had to take a sick leave...
The further we are in a project, the more we know about it and only then we can tell whether we'll be on time. Sometimes we have to re-estimate or reevaluate.
and estimates is what it is: an estimate. An estimate is a guess. No commitment is implied. No promise is made. Missing an estimate is not in any way dishonorable. The reason we make estimates is that we don’t know how long something will take.
The problem here is that business and management often view estimates as commitments.
Yeah, I believe I will read this post again in a few weeks. The team's manager decided we were not fast enough, so he decided to bring three new developers at the same time to finish a project in a month.
I am sure this is going to be a lot of fun. I honestly can't see how this project is not heading to a catastrophic outcome.
You're manager might benefit from reading the mythical man hour.
Any impressions after "few" weeks?
Where to begin? Turned out the new developers didn’t know the tech we were using, so they built the same project from scratch but with the tech they were familiar with. Me, I moved to another project in the mean time. Long story short, the product is launched tomorrow :D
That’s a solid 3 months delay at least. If that was not poor management, I don’t know what is. Thankfully, not every project happens this way, we’ve been safe from this madness since then, but dealing with higher-ups like that can be very stressful.
aka "million monkey approach".
"Nine women can't give birth to a baby in a month!"
So funny.... Thanks...
Hahaha, pretty cool!
Haha! I didn't hear that one before
Instruct your manager to read “The Mythical Man Month”
...and provide 3 copies of it so he or she can read it 3 times as fast!
Ask the manager if (s)he heard about Brook's law: "Adding manpower to a late software project makes it later".
Later is even more fun than late :>
Good luck!
Thanks :D