181–190 of 387 posts
Oh, and from working side-by-side with the best practitioners in the business at ThoughtWorks for three years. But the book is sufficient.
Earlier quoted context omitted.
One amendment I always wanted to make was to have a "technical debt dial". You could stick it on the wall next to the scrum board. The debt dial should be from 0% (spend all the time refactoring) to 100% (spend zero time refactoring, get it out at all costs). Management should have complete control over the dial. Developers should have control over what kind of refactoring they do (ideally the retro should have a que…
I often have the impression that the term "technical debt" is just an euphemism to avoid admitting that someone in the team has produced poorly thought and poorly written code. I'm not sure I ever found myself in the position of writing bad code just for the sake of speed - I surely wrote tons of bad code because I didn't know how to do it better, or because I didn't have the requirements clear from the start, or bec…
One of the most essential part about Scrum is that it aligns the understanding across all the stakeholders, including business owner, customer, designer, developer etc. Hence the meeting, prioritization, backlog, daily standup/daily write up as development process artifact etc to focus on the priorities that create the most business value under flexible scope, fixed time and fixed money. scope, time and money are the…
So Engineers get herded into little incremental projects that management can swallow as having 'business value'. And the herd marches toward the cliff as the code base wanders around the solution space but never gets fundamentally sound. Anyway, that's my jaded (from experience) view.
Earlier quoted context omitted.
One amendment I always wanted to make was to have a "technical debt dial". You could stick it on the wall next to the scrum board. The debt dial should be from 0% (spend all the time refactoring) to 100% (spend zero time refactoring, get it out at all costs). Management should have complete control over the dial. Developers should have control over what kind of refactoring they do (ideally the retro should have a que…
One question I have is how does one actually objectively measure technical debt? I mean by anything more than a guess or intuition. Does every singleton/global variable count? Does every comment with a HACK count? What other factors contribute to technical debt, and by how much?
The time it takes to change code that is already written.
For instance, if you want feature N+1, but to do feature N+1 you need to change feature N, then the amount of time you spend changing feature N is the technical debt.
So when you are estimating, you could say: We need to refrob the whozzit to make it compatible with foo 2.0, then that work could be captured as technical debt.
Earlier quoted context omitted.
Because that two weeks you spent writing excellent code is mostly useless unless you have a way to get feedback on it. As a customer, you've given me no value. What if you finally hook up UI to the sub-component and the customer/stakeholder decides they don't like any of it? You could have known about it earlier.
That's why I sometimes say at my workplace that we should make our projects in Flash. Faster to make an interactive UI this way and get the approval of the management/customer, no time wasted on useless things like having the program actually work in an efficient, useful and secure way.
Earlier quoted context omitted.
One amendment I always wanted to make was to have a "technical debt dial". You could stick it on the wall next to the scrum board. The debt dial should be from 0% (spend all the time refactoring) to 100% (spend zero time refactoring, get it out at all costs). Management should have complete control over the dial. Developers should have control over what kind of refactoring they do (ideally the retro should have a que…
I often have the impression that the term "technical debt" is just an euphemism to avoid admitting that someone in the team has produced poorly thought and poorly written code. I'm not sure I ever found myself in the position of writing bad code just for the sake of speed - I surely wrote tons of bad code because I didn't know how to do it better, or because I didn't have the requirements clear from the start, or bec…
Time constraints can certainly be relevant too. It's not always an artificial shift of blame. For instance, time constraints could be why the code passed review to begin with.
And some programmers certainly do write worse code when they have to do it quickly. Typically, the code itself doesn't look all that bad in a vacuum, but it presents problems months down the line when a new feature needs to be added or an existing one changed in a non-trivial way. There was little forethought in its design.
Or, let's just look at the ways you said you might write bad code:
> I surely wrote tons of bad code because I didn't know how to do it better, or because I didn't have the requirements clear from the start, or because of bad design and planning
In other words, these things can cause you to write bad code:
1. You just didn't know better.
2. Unclear requirements at the start.
3. Bad design and planning.
In (1), you might realize after writing some code that you didn't quite know what you were doing and you should refactor it, but you're now under pressure from management to just get it out. Oops, no time to refactor. Now code that you know is bad is going into production, and it'll bite you in six months.
For (2), the reason the requirements weren't clear is because not enough time was spent by management/product owners/designers on clarifying said requirements.
For (3), it's the same thing -- bad planning is often the result of time constraints (notably, time constraints which may not be visible to you as a rank and file programmer).
That's a really good point. I'd be excited to see what a team could do if each developer wrote a one-page memo about what he did and what he was going to do once an iteration, and a few sentences for each day. Throw 'em in a log, and they might even aid the retrospective.
Scrum proponents (a label I would tentatively apply to myself) would tell you that 'you're doing it wrong' but unfortunately a point-by-point reply to this article would detract from the general problem here: Scrum is intended to be the straightest line towards measuring your real progress on a project, and not much else If youre working on a project where it is important that you have as-accurate-as-is-realistic an…
"Scrum is intended to be the straightest line towards measuring your real progress on a project, and not much else." More like wandering in the desert, hoping you find the promised land. Been thru scrum master training 3 times, been on many "agile" teams. I've never heard this rationalization. Rather, a common justification for "agile" was you always have a working product. Which might be nice if things worked out th…
Earlier quoted context omitted.
Describing drawbacks and problems is value added. Theoretical physicists regularly know about problems for decades before solutions are found. Precisely describing the problem can get the intelligent diaspora organized around finding improvements to the situation.
Did you just compare a project management methodology with theoretical physics? Sounds to me like you try to compare apple with orange. Sorry, I don't follow you.