search

Readify / madskillz

Readify Mad Skillz
Other
88 stars 39 forks source link

SD - setting technical direction #26

Closed rbanks54 closed 6 years ago

rbanks54 commented 9 years ago

I am comfortable setting technical direction for brown-fields product, reducing technical debt

Given setting technical direction is usually only done for green fields or major rewrite projects, how about we reword this slightly as the following

Would that work better? Or do you have other improved wording that might hit the mark better?

aaronpowell commented 9 years ago

I'm not a fan of the word tweaking as how would you demonstrate something as tweaked. I also think that understanding the why and not just doing something "cuz I say it's better" is important

robdmoore commented 9 years ago

Looks good aaron

Rob Moore | Readify Principal Consultant, Technical Specialist (Microsoft Azure) | m +61 400 777 763 | e rob.moore@readify.net | w readify.net

On 19 May 2015, at 9:08 am, Aaron Powell notifications@github.com wrote:

I am comfortable improved brown fields products by understanding current technical approaches and implementing improvements, introducing new design patterns and reducing technical debt as appropriate I'm not a fan of the word tweaking as how would you demonstrate something as tweaked. I also think that understanding the why and not just doing something "cuz I say it's better" is important

— Reply to this email directly or view it on GitHub.

rbanks54 commented 9 years ago

@aaronpowell Good call.

cottsak commented 9 years ago

I disagree with the premise that technical direction is usually only done for green fields or major rewrite projects. I read "technical direction" as any approach/plan/strategy to manage the technical side of a project going forward. Many brown-fields or "legacy" systems are not major rewrites. They're just in "maintenance mode" or perhaps we only have a few weeks to "add these 3 new features". The "technical direction" defines the team's approach to delivering given the all the context of the legacy system - what we are going to change/improve and what we are not. I think the statement in it's current form is very good.

michaelnoonan commented 9 years ago

@cottsak That's kind of the gist we were driving at originally: The ability to take stock of an existing code base and figure out how to "move the ball forward", avoiding the tempting hacks that potentially increase technical debt.

rbanks54 commented 9 years ago

@cottsak You have a very different view of "technical direction" than most people I talk to :-) In my experience most people see "technical direction" as architecture work, platform choice, language and tooling to use going forward, and standards setting for future development. I'd regard your specific example to be aligned with this SD skill:

I know how to make pragmatic choices in order to ship a product.

cottsak commented 9 years ago

@rbanks54 Fair. Then perhaps "technical direction" is not as commonly understood as once thought? Perhaps it needs to be expanded a little by maybe adding another sentence to the one liner?

rbanks54 commented 9 years ago

@cottsak That was the intent of the proposed rewording. Maybe @michaelnoonan can provide a better alternative?

WillRay commented 6 years ago

@rbanks54 is this issue still relevant? It looks like changes over the years have addressed this.

In particular, these three bullet points seem to tackle it:

I am trusted to ship full products (or vertical slices of larger products) from idea to production.

  • I am proficient at qualifying and reducing technical debt.
  • I am comfortable determining technical direction within brown-fields projects.
  • I know how to make pragmatic decisions in order to ship a product.
rbanks54 commented 6 years ago

@WillRay Hmmm... maybe if all three are taken together, but the separated nature of the points makes it easy to focus only on one item at a time

rbanks54 commented 6 years ago

That said, I'm happy to let this one lapse now. I'll close the issue.