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