However, working with legacy, you often find techdebt or inadequate architecture/infrastructure mid project...
1,064 karma · joined October 28, 2016
However, working with legacy, you often find techdebt or inadequate architecture/infrastructure mid project...
For example check out the "Greening the desert" project.
Can you recommend anything from him that is more readable?
===
[1]https://www.amazon.de/-/en/Robert-David-Steele/dp/1583944435
[2] https://www.amazon.de/Best-That-Money-Cant-Buy-ebook/dp/B077...
Hmmm so plankton is 50-85% and diatoms are 25-50%? So how much are plants adding?
https://books.google.de/books?id=uzJbyD6_3DAC&pg=PA4
And yes you have to be consistent and stay in that unit system. The other remaining two we used plain Kelvin for temperature and for the charge Coulomb was measures in electron charge. That's it.
Neural forecasting: Introduction and literature overview
1. Severity - roughly defined as in the article
2. Occurrence - How probable will this bug happen in the field? How many users would be impacted? How much support will be needed for this issue? Low - Only some very special workflows or mainly dev work impacted. Medium - Some regular users. High - Many regular users.
3. Reproducibility - How often will the bug occur when we follow the steps. Low - Single occurrence or difficult to reproduce Medium - Erratic behavior, thread problems High - It will almost always happen.
Then a PO can set a prio and give the ticket the status "will not fix" or "to be analyzed". The dev team then takes the bug and does a time boxed (1 day max) first analysis and comes back with an effort estimate of how big the issue it's too fix. Then a PO can reprioritize and set the status to "to be fixed" or not.
Did that not lead to a super competitive workplace? I cannot imagine that this was very motivating to the remaining 990 devs... Or was it?
# Risk
* What are the platform constraints?
* What are the performance constraints?
* Get clarity to what is an acceptable upper bound.
* Would it be acceptable if it took a week to calculate or 20 minutes to open the application?
* Does it need to happen in 30 seconds or 5 milliseconds or 100 microseconds?
* Can you demonstrate a failure?
* What happens when you go off script?
* Most of the complexity is in handling those off-script behaviors. If that’s not being handled well, the project is definitely not “nearly done”.
# Definition of done
* How does the “Definition of Done” look like? Ideally from whole project down to single stories.
* How would you verify that this is working correctly?
* What is the success criteria of this product?
* What does “good” look like?
* What will make it a worthwhile endeavor?
* What are other pain points and blockers?
# Costs
## Opportunity costs
* Is this the most valuable thing we can be doing?
* Is an 80% solution good enough for your needs?
* Is this work really where your team can add unique value?
Other question one might ask to get a feel for the lost opportunities:
* Which parts of the current system are hard to use?
* Which manual process stops the customer to do more creative, value-adding work?
* What changes would improve operational inefficiencies and save money from the bottom line?
* What evidence can you show that this will solve the problem?
* Provide a simulation or prototype or fake (but statistically relevant) data which can demonstrate the solution is at least plausible.
## What connects to this?
* Things with a more complex network of dependencies will be more costly to develop and maintain.
* What systems will depend on this?
* What systems will this depend on? Enumerate all the dependencies. Other systems, libraries, users, protocols, everything
## What’s Plan B if this doesn’t work?
* What are you going to do when we’re up against a deadline, this solution isn’t working as expected, everything is broken, and we still have to ship?
* Get an answer to that, then do that first. Then you can talk about how you can make it better.
* What would be the earliest point you can know whether the system has any value to you? What is the smallest step that would give us the most benefit? How will we do this?
* If we could keep only half the features what would they be?
* What if we take one dev away from this project?
* The 80/50 Rule:
If you’re not 80% done by the time you’ve used 50% of your resources, you are behind. When something doesn’t pass this test, it’s time to evaluate what needs to change:
* Does this project need to stop?
* Do other projects need to move? “I can make up the time” is not a realistic response.
# Maintenance cost
* How long will the system survive?
* When will this system be scheduled for replacement?
* During what period will you be making no changes to the system except for critical bug fixes?
* What are the prerequisites for using the solution?
* What must continue to be true?
* What do users need to know?
* What does the data need to look like?
https://github.com/frankMilde/interesting-reads/blob/master/...
In principle I think you are right, but that would mean for each plant you build you need the exact position of each mirror, the oven chamber and the motion of the sun through the day and year. I think the "AI" approach scales better, as it is rather simple "AI" application.
===
[1] https://www.amazon.com/-/de/dp/0804795800/ref=mp_s_a_1_8?key...