Algorithms we develop software by
grantslatton.com
Algorithms we develop software by
1–10 of 108 posts
Re: Algorithms we develop software by
#2> "gun to your head, you have to finish in 24 hours, what do you do?"
PSA: if you are a project manager / owner or some other similar position you do not get to ask this. This is a personal educational excercise not a way to get stuff done faster.
Re: Algorithms we develop software by
#3> "gun to your head, you have to finish in 24 hours, what do you do?" PSA: if you are a project manager / owner or some other similar position you do not get to ask this. This is a personal educational excercise not a way to get stuff done faster.
"gun to your head" is maybe not appropriate for work, but the exercise is good for cutting to the core of a task when necessary. It's really the same question as what is the minimum viable product.
Re: Algorithms we develop software by
#4> "gun to your head, you have to finish in 24 hours, what do you do?" PSA: if you are a project manager / owner or some other similar position you do not get to ask this. This is a personal educational excercise not a way to get stuff done faster.
"gun to your head" is maybe not appropriate for work, but the exercise is good for cutting to the core of a task when necessary. It's really the same question as what is the minimum viable product.
Yeah, I've certainly seen cases where something was overbuilt and 90% of the time was wasted.
But I've also worked at places where things were underbuilt (e.g 0 test environments whatsoever except prod). If there was a gun to my head, to finish something in 1 hour, I'd test in prod.
So I think advice that sometimes is useful, sometimes is damaging, isn't really helpful. Not unless there's an easy way to tell which situation is which.
Re: Algorithms we develop software by
#5> "gun to your head, you have to finish in 24 hours, what do you do?" PSA: if you are a project manager / owner or some other similar position you do not get to ask this. This is a personal educational excercise not a way to get stuff done faster.
> In practice, none of the day-long plans are actually a day. The gun isn't actually to your head. You can go home and sleep.
Re: Algorithms we develop software by
#6"Write everything twice" is a great heuristic. Extreme programming and unit tests is a dumb and wasteful technique. You end up cornering yourself.
Re: Algorithms we develop software by
#7Write everything (generally, new features) twice has turned out to be really good strategy for me, but it doesn't sit well with bizdev or project managers and tends to be perceived as unnecessary slowness.
But if you plow through a feature and get it "working," you'll do much of that work cleaning up the logic and refactoring through your first pass. What rewriting allows you to do is crystalize the logic flow you developed the first time and start cherry-picking in a more linear fashion to meet the blueprint. It also tends to reduce the urge (/ need) for larger scale refactorings later on.
Re: Algorithms we develop software by
#8"Write everything twice" is a great heuristic. Extreme programming and unit tests is a dumb and wasteful technique. You end up cornering yourself.
Sorry, are you saying unit testing is dumb? Not that you'd be the first to say such a thing, but I've never really understood this if people find them valuable. 100% test coverage is one thing, but having some interdependent functions that do one small thing is a perfect use case for unit tests.
Re: Algorithms we develop software by
#9"Write everything twice" is a great heuristic. Extreme programming and unit tests is a dumb and wasteful technique. You end up cornering yourself.
"Write everything twice" is sometimes called a "spike."[0]
> A spike is a product development method originating from extreme programming that uses the simplest possible program to explore potential solutions.
In my career, I have often spiked a solution, thrown it away, and then written a test to drive out a worthy implementation.
0. https://en.wikipedia.org/wiki/Spike_(software_development)
Re: Algorithms we develop software by
#10> "gun to your head, you have to finish in 24 hours, what do you do?" PSA: if you are a project manager / owner or some other similar position you do not get to ask this. This is a personal educational excercise not a way to get stuff done faster.
100% this should never be an excuse to push for a faster outcome. I have to admit though, as a personal mental exercise, this has saved me countless of hours from going down the rabbit hole of over-engineering. Some problems just need a simple solution, sometimes even without any changes to code.