What can you really build in a weekend?
The core functionality with happy path? Probably, yes.
But will it be useful? I doubt it.
Can you add su...
For further actions, you may consider blocking this person and/or reporting abuse
Counter-intuitively I think the most impactful opportunity to "build it within a weekend" is in the context of large existing products where a lot of edge cases are already accounted for and you get the chance to focus in on one hyper-productive use case.
Bigger companies and larger user bases naturally have higher bars for security, user experience, business needs, QA, product sign off, etc. So actually threading that needle is nearly impossible in practice — but that is where the opportunity really lies — vs greenfield projects where you can build the happy path in a week and are left with a gigantic uphill battle to actually deliver value.
You're essentially saying a feature can be built in a weekend, especially in bigger companies.
I definitely buy that, mostly because all the things that take a lot of time has been done before that!
Yes I agree.
My emphasis is that this feature has the potential to be more impactful than people realize.
So basically: People over-estimate their ability in the way you're describing, but organizations with "brownfield products" struggle to achieve hypothetically possible outcomes of highly impactful features which could or should be "two day projects" and instead turn them into multi-month projects which might go nowhere.
It's a hard problem to solve for, but I feel like people think that when people think "what can get done in a very short amount of time" they usually think about brand new projects whereas I think the focus on existing ecosystems is where the opportunity is.
Ahh, yeah makes sense!
And the emphasis on making it for scale also stretches the timeline by a fair bit!
Focusing on existing ecosystem is I feel more of an ego issue (problem not sexy enough, can't get promoted) 😅
I did not even read the article but only the title and it amazes me how developers pride themselves on their ability to rush through something and get it out within a day. This defeats a lot of software engineering principles where accounting for edge cases is more important than the happy case because there are more ways that a piece of software can go wrong than right. Also, there is practices such as defensive programming which is very important for more mature developers.
To me, developers who pride themselves on how quickly they can get something out is a bad metric for successful software delivery.
Rome wasn't built in a day :)
That is true, I mean this politely but what does your response have to do with what I stated initially? Any company with a solid defensive programming strategy would not allow a developer to develop something and push it to production without quality gates in place. A software engineer's job is to be resistant to introducing code into a system.
I meant that things take time to get up and running, and work efficiently
Agreed!
Obligatory mention of the 80-20 rule. Often you can build something 80% functional in a weekend. It's the last 20% that takes a while :) I see this pattern play out sometimes after our internal hackathons. Someone throws something demo-able together in a day, but making it production ready takes a lot longer (if we even decide to do that).
80-20 is the perfect way to describe this feeling!
I tend to flip it around and do the 20% first and then do the 80% (implementation) as that is the best way to go about it. Some people create the path and build while I prefer to open the path and determine what is needed beforehand so that the road is clear for development.
Yep
God lies in the details. And the details take a lot longer than the other parts.
reminds me of those tutorials to "make a YouTube clone" in 4 hours features 40 lines of JSX code!
Here's a full list! - youtube.com/playlist?list=PL-J2q3G...
Building a prototype and push it to users after a weekends work can easily become a "fixing the planes engine in the middle of the flight" escenario.
Yes a great proof of concept can be done in a couple of days, but to transition that into a business will require many, many weekends.
Agreed!
Building a project in a weekend can achieve core functionality, but deeper aspects like customization, error handling, security, and compliance may require more time. Consider ford fiesta 2009 prioritizing features and refining them over time for a more robust and useful end product.
I think at least one week for me is a relevant time span to build something usefull. But! Once this proto can move somehow, yes there will be a lot of work on error handling, styling and other polishing...
I know people who make landing pages within a couple of days, however, it's only about ordinary templated websites...
Building a project in a weekend sounds exciting, but ensuring it's truly functional and user-friendly involves more than just core functionality. It's essential to consider user customization, error handling, security measures, and Wash Clothes optimization for different platforms. Additionally, integrating features like admin panels, customer support tools, and payment flows enhances its usability and value. It's a comprehensive process that requires careful planning and execution beyond the initial build.
How
brings to mind those four-hour tutorials that teach you how to "make a YouTube clone" using 40 lines of JSX code!