Ref: https://www.youtube.com/watch?v=LLEXAdO3X1o
Agile: able to move quickly and easily, quick movement
- Prioritising business goals over technical excellence
The over-engineered Agile approach is gonna spoil both Business Goals and Technical Excellence.
Agile - And if your application architecture sucks - code quality drops
Agility is an observation, can I move the code quickly and easily?
The software where you are working on, is it agile?
Feature work vs. technical Work: people create this, this is a false dichotomy
Feature work is technical work. People don't think like this.
Features are made of software which is technical work.
You need to figure out business value, which varies from context to context.
Business value and also varies by time, when thinking in the perspective of business value, you should think on business value over a day, over a week, a month, an year, a decade
Challenge Somebody on business value.
prioritise by business value -> prioritize the backlog
No Product Owner / No Business owner knows the business value. The only way you know the business value is by building it, shipping it and observing the value generation over time and then comparing it with our initial assessment.
Prioritize by business value estimate(d). Semantics means meanings. Actuals not an estimate. There is vagueness in the lang we speak i.e we dont know the stuff.
"Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change" by Grady Booch
Where do you spend time and money. Less
What effect does ignoring quality have in the long term ?
- It has no effect? : Well its impossible answer, someone gave this answer ? interesting
- It reduces the cost? probably in the term, then mark it for later review
- It increases the cost ? then pickup immediately and reduce the cost
Technical debt is an effect, what is the cause of this ?
We distracted by wrong thing, what is the cause by debt ?
Technical Neglect:
tech debt - legacy code
Practical Example: A boat on the water, people are throwing the water outside instead of fixing the whole from where water coming to the boat. This is technical debt.
As an evolving program is continually changed, its complexity, reflecting deteriorating structure, increases unless work is done to maintain or reduce it. By Meir M Legman
Legacy born in 1989 in software world.
maintenance -> deteriorating the code -> by adding a new feature -> then you should maintain the structure of the program
Time Is Money -> We are lending money and converting that into money
Arguments is war
Arguments are buildings
Love is journey
Happy is up, sad is down
To be considered good, a metaphor has to offer a number of points of useful correspondence with what is being described.
Another quality is good metaphor is that it should not have too many obvious points of conflict
The Third quality of a metaphor that makes it effective is familiarity to its audience
Martin Flower: Technical debt is a wonderful metaphor developed by Ward Cunningham, in this metaphor, doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt.
Shipping first time code is like going into debt, A little debt speeds development so long as it is paid back promptly with a rewrite.
Create a thing - get the feedback - respond - add a feature -> deliver - > get the feedback
A structured debit is good, its not bad like a house loan.
Bad Science : You cant convert technical debt into financial debt, its unmanaged technical debt.
Technical debt is not the cost of repaying the debt: it is the cost of owning the debt. These are not the same.
In summary in my words
- Technical debt is not something that we think is technical debt
- technical debt cant be converted into money
- you should convert the value lost due to technical debt as its technical debt
- you should always follow the structure of your architecture to avoid more technical debt
- If you are working on something always ask, is it adding any value?
- A value by fixing a debt in terms of loss might approach by not fixing it.
- if your developers are spending a lot of time of understanding the past code instead of adding new features then you are not adding much value.
- Here the point is, why your developers are spending time to understand the code, why cant the developers who have idea on the code can't fix it while the new developers can work on features
0 comments:
Post a Comment