No, no, no, no, and no. And no.
A big NO. Clear as that.
All you have to do is to bring those two letters together and say the word.
Now, let’s ...
For further actions, you may consider blocking this person and/or reporting abuse
The key is, indeed, to know when to say no. That doesn't mean "always say no". It means to be judicious. You wrote this article as though your only options are scope explosion or iron-fisted scope control, but that's just not the case. If you know exactly and explicitly what you need to make, you can stick to this advice. But, in practice, even if yout think you know, you don't. You always have to make changes and update what you thought you knew.
You are right. But if we are aware of what we are doing and the costs of our choices, we will get better. My aim with this article was to increase awareness of developers.
Fair enough! My only concern is that a junior developer will read this and take from it the bad idea of refusing all scope increases. I agree that scope creep is a bad thing in general, but there are times when it makes perfect sense.
For example, let's continue on the example of the email client. Sure, it can send and receive emails, and that's the barebones requirements. But now, every email you get is all in the same list, whether they're racist forwards from your "I'm not racist, but..." uncle or from that big new client you just netted. So clearly, some sort of filtering is useful. Even though that's an increase in scope, it's still worth it to add, because that's a vital feature.
That's what I meant by "that's just not the case" -- sure, you might think you know exactly what you're making, but even the most detailed specs can't account for everything.
Then again....if you're getting paid by the hour.... :)
Hehe!
Sounds cool in the beginning but can be a bullet in your own feet when the project gets bigger. You will get more and more expensive with less capability in the eye's of the management.
More often than not writing less code require more time, because writing good, bug-free feature takes thought, refactoring, writing tests.
Spoken like a true consultant. lol
This is great. Even for things you say yes to, it's worth the time to do non-coding activities to keep your project clean and easy to change:
Meh. This is good advice for engineering useless products. There are a million products out there that send and receive emails. Write the code that improves the user's experience with your email app and distinguishes it from the others. Write expressive, self documenting code and supplement it with actual documentation that explains the context of the code. Saying yes is important, too, obviously.
This is just an example. I think you already got the point:)
I could not agree more with what you've said Hüseyin, it's cool to accept challenges from time to time because by doing that we can expand our comfort zone, but also is important to acknoledge our own skill limitations so we don't fall in the mistake of compromising with a client that we cannot satisfy in the time the project is expected. :)
This is incredibly good advice
Great article and great advice !
It's so true !
+1000
It's a good thing to be able to work at a company where asking why is allowed.
Nice tip.
It is hardest to evaluate when you are the only developer in the project.