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.
Top comments (38)
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.
"Nine women can't give birth to a baby in a month!"
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!
Hahaha, pretty cool!
So funny.... Thanks...
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
aka "million monkey approach".
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.
You're manager might benefit from reading the mythical man hour.
Great post! I'd also definitely recommend a third (and often less controllable) option: cutting scope to keep to your code quality practices and team norms.
As a line developer this can be difficult, but by working together with management / product ownership to distill the feature you're working on down to the things it really needs (and not less valuable fluff) may provide some space in the other two areas of the classic project management triangle (time and quality).
Glad to have seen this discussion!
While I'm currently between positions, I've had more reading time, and have recently discovered the concept of Minimum Viable Product (MVP).
I've had recent experience with a team needing (under very tight time constraints) to get enough of a product (in this case a web application) built and rolled out quickly simplify to satisfy requirements for continuing the project. From a rather junior role, I learned a great deal walking through that process of distinguishing 'need from want'... and how critical it is to have foresight when pre-planning the timeline, setting up milestones, defining sprints, etc.
At the same time, I'm also reading about some of the common struggles that those of us new to the field face (learning curves, confidence, time/task management)... and seeing that it's very common for newer developers to try to get everything perfect before committing (which ultimately prohibits one from committing anything... and another lesson learned), when it's often more practical to just get it into the repo (or review, etc.) as a working version, and then fine-tune for style as a function of tech debt.
The two concepts (to me, anyway) seem to have a real parallel. MVP for quick out-the-door iteration, and not sitting on code that's functionally working.
I know for me that the whole balancing time/scope/quality, just within my own working context, has been challenging.
Thanks for a great thread (and yes, in fact that was the first instance of my using markdown in-line without a cheat sheet :P )!
There's a thin line with good work and actually overdoing things.
No code is perfect at first sitting. We have pair programming and code reviews to help :) But being too much of a perfectionist is no good too.
We have to help each other to keep the right balance here :)
Thanks!
Managing the scope creep is pretty reasonable. If you work on this with the business side you can deliver extra fluff in the next batch/release (if needed).
I don't recommend cutting corners and working too much overtime. I mean overtime once in a while is fine, but there are managers that think overtime is normal. "Developers don't have normal life after work after all"
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.
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.
"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) ;)
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 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 ;)
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.
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.
You should read The Mythical Man Month and Peopleware