6 ms·

I have built many things in my short career, have worked at big and small companies. In my view iterative development is far harder, maybe even impossible, to

by lbacaj 8y ago

I have built many things in my short career, have worked at big and small companies. In my view iterative development is far harder, maybe even impossible, to do at companies that don’t have the culture for it. Startups have it and most grow up with it but you’ll struggle to succeed with this approach at any big company. They may introduce Agile and bring in Agile coaches but they are just putting lipstick on the pig. That culture is set, I say this having seen it first hand. As an example, and a little self promotion that I hope I won’t get downvoted for :) I have been working on a cross platform App that reads any article to you. It uses AI/ML models to convert the text to audio so you can listen on the go and maximize learning on that dead time on commutes. This is a fairly complex thing to build, especially in a few months and to make it work cross platform. We now have a lot of features but this all happened feature by feature. Get one thing done, get it out, start on the next thing. If I tried this approach in a big team at a big company there is absolutely no way we would have this much done in a few months. The politics, the nonsense, etc. If you want to check out the app you can try it here: https://articulu.com https://articulu.com

stronglikedan 8y ago
Nit: (from Play Store page) "Articulu is available for Android, the web, and any other phone." makes it seem like there's a web version, but I couldn't find one.
tokyodude 8y ago
I'm probably in the minority but I wasn't willing to sign up just to see a demo. Maybe put a video or something on your site?
ravenstine 8y ago
In my experience, many companies that are writing software have no business doing so.
williamdclt 8y ago
I kinda agree with you, but I did see it working in big corporates too. And each time it worked, it's because they created some "internal startup", self-organised, cross-functional unit for the particular project (and got help from people that had experience in agile/lean methodologies)
chooseaname 8y ago
From what I have seen, the first version is more iterative. When the inevitable re-write happens, architecture astronauting happens. Devs get this mindset that they can build a Neo[0] system that can handle any future feature request and so the product stalls. And stalls. And ... well you get the picture. [0] "The One..."
- mattnewton 8y ago
  I think experiencing that kind of behavior is what led Joel Spolsky to write about how you should never rewrite something from scratch https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...
- tveita 8y ago
  This is commonly known as the second-system effect, named by Fred Brooks.
cheez 8y ago
With large companies, I find what works well is "this is going to take 5 years, what should we do in a month?" From 0 to working in a month usually gets the check writers to open up.
Gpetrium 8y ago
Iterative development, Agile, Design Thinking, DevOps are all areas that require some form of culture change to teams & sometimes company. It is possible to create small teams that are driven by some or all of the items listed above, however, they usually need to be insulated from the rest by management. Will there be spillover on both sides? Very likely, but the idea is to get the wheel moving forward. The process of moving a medium-large businesses towards a more 'Agile' mindset for example, can be dreadfully slow with plenty of roadblocks throughout the process and that can cause some executives to want to go back to their previous ways. Realistically speaking, some companies are better-off starting to implement some areas of the items listed above and in steps, add the other areas that are relevant to the success of the company. Not all areas of Design Thinking for example, will be applicable to all segments of the company, understanding which ones to add, when and the costs/benefits of not having the other areas is really what drives success
rladd 8y ago
Your sentence rendering is very impressive and lifelike. Great job! One suggestion: pause a bit more after the end of paragraphs, particularly after long paragraphs. It can help comprehension.
- hellohellohihi 8y ago
  +1 on the sentence rendering. I've been looking for a tool like this for quite some time and was pleasantly surprised by the quality! At some point down the road, it'd be nice to have the ability to adjust playback speed.

by lbacaj 8y ago

stronglikedan 8y ago

Nit: (from Play Store page) "Articulu is available for Android, the web, and any other phone." makes it seem like there's a web version, but I couldn't find one.

tokyodude 8y ago

I'm probably in the minority but I wasn't willing to sign up just to see a demo. Maybe put a video or something on your site?

ravenstine 8y ago

In my experience, many companies that are writing software have no business doing so.

williamdclt 8y ago

I kinda agree with you, but I did see it working in big corporates too. And each time it worked, it's because they created some "internal startup", self-organised, cross-functional unit for the particular project (and got help from people that had experience in agile/lean methodologies)

chooseaname 8y ago

From what I have seen, the first version is more iterative. When the inevitable re-write happens, architecture astronauting happens. Devs get this mindset that they can build a Neo[0] system that can handle any future feature request and so the product stalls. And stalls. And ... well you get the picture. [0] "The One..."

mattnewton 8y ago
I think experiencing that kind of behavior is what led Joel Spolsky to write about how you should never rewrite something from scratch https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...
tveita 8y ago
This is commonly known as the second-system effect, named by Fred Brooks.

cheez 8y ago

With large companies, I find what works well is "this is going to take 5 years, what should we do in a month?" From 0 to working in a month usually gets the check writers to open up.

Gpetrium 8y ago

Iterative development, Agile, Design Thinking, DevOps are all areas that require some form of culture change to teams & sometimes company. It is possible to create small teams that are driven by some or all of the items listed above, however, they usually need to be insulated from the rest by management. Will there be spillover on both sides? Very likely, but the idea is to get the wheel moving forward. The process of moving a medium-large businesses towards a more 'Agile' mindset for example, can be dreadfully slow with plenty of roadblocks throughout the process and that can cause some executives to want to go back to their previous ways. Realistically speaking, some companies are better-off starting to implement some areas of the items listed above and in steps, add the other areas that are relevant to the success of the company. Not all areas of Design Thinking for example, will be applicable to all segments of the company, understanding which ones to add, when and the costs/benefits of not having the other areas is really what drives success

rladd 8y ago

Your sentence rendering is very impressive and lifelike. Great job! One suggestion: pause a bit more after the end of paragraphs, particularly after long paragraphs. It can help comprehension.

hellohellohihi 8y ago
+1 on the sentence rendering. I've been looking for a tool like this for quite some time and was pleasantly surprised by the quality! At some point down the road, it'd be nice to have the ability to adjust playback speed.