5 ms·

This type of analysis paralysis will kill your project. > I have to think about the future, and so I have to try to make the right choice on this.. You don't

This type of analysis paralysis will kill your project. > I have to think about the future, and so I have to try to make the right choice on this.. You don't have to make the right choice right now. For now, focus on getting something complete so that you can prove the idea out.

codecamper 10y ago
separation of concerns. Just write the logic in a fairly portable language.
- jventura 10y ago
  I do have it in Python! I've successfully build some frontend experiments with Android (http://joaoventura.net/blog/2014/python-android/ http://joaoventura.net/blog/2014/python-android/), Web (with Flask) and Qt (PyQt5 and pyotherside). My problem is with the choice of the best frontend approach, and since I'm only one guy working on this, I am trying to find my "best" decision..
  - Retric 10y ago
    Generally, if it works as a website use that. Desktop apps are for things you can't do with a website. EX: File system tools, AAA FPS, etc.
stcredzero 10y ago
It's not about making the ultimate right choice. It's about not getting trapped in a dead end, or in a situation where you can't change your mind.
- partisan 10y ago
  There is virtually no dead end corner that the OP can paint him/herself into. They could pick literally any language or approach, platform or format, and create a successful business from it. The risks come from not being able to _easily_ make changes, but those risks are mitigated by the choices you make in developing the software, at an architecture level, using proper design and weighing out the realistic possibilities, not the universe thereof. Concretely, if you create a web-based API, then you can put any front-end on it. If you layer the application correctly, you can move some of the layers closer to the client as needed, adding caching for performance. If the problem is one that can only be solved through a desktop application, then the whole question was moot to begin with. I've seen enough Excel-spreadsheets-as-million-dollar-business to know that the only thing standing between you and your completed product is yourself, especially when you have technical skills to actually do the work.
  - stcredzero 10y ago
    The risks come from not being able to _easily_ make changes In my experience, this is pretty much the same thing as being unable to change your mind.
    - partisan 10y ago
      If you are a developer and good at what you do, you will layer your application to buffer against changes. If you aren't then just write the code the best you know how because building a business AND learning how to be a good coder at the same time is not the most efficient path. That path is littered with constantly rewritten, half-finished, failures. Get a product out and then figure out where you could have done better.
      - stcredzero 10y ago
        If you are a developer and good at what you do, you will layer your application to buffer against changes. That's a good place to start. That's 80's and 90's best practice, though. (Most of the industry is stuck in this mindset, to be fair.) I'd say the 21st century version of this would be to structure your code in such a way that transformation tools can be easily applied.
        partisan 10y ago
        So you understand my point.
        stcredzero 10y ago
        The code architecture "win" is always to dodge the big manual rewrite. The "lose" is to have to do the big manual rewrite. People make it into a game of ideological purism, but really, it's as simple and pragmatic as just that. They who dodge the manual rewrite -- those are the real gurus.
        10y ago

codecamper 10y ago

separation of concerns. Just write the logic in a fairly portable language.

jventura 10y ago
I do have it in Python! I've successfully build some frontend experiments with Android (http://joaoventura.net/blog/2014/python-android/ http://joaoventura.net/blog/2014/python-android/), Web (with Flask) and Qt (PyQt5 and pyotherside). My problem is with the choice of the best frontend approach, and since I'm only one guy working on this, I am trying to find my "best" decision..
- Retric 10y ago
  Generally, if it works as a website use that. Desktop apps are for things you can't do with a website. EX: File system tools, AAA FPS, etc.

stcredzero 10y ago

It's not about making the ultimate right choice. It's about not getting trapped in a dead end, or in a situation where you can't change your mind.

partisan 10y ago
There is virtually no dead end corner that the OP can paint him/herself into. They could pick literally any language or approach, platform or format, and create a successful business from it. The risks come from not being able to _easily_ make changes, but those risks are mitigated by the choices you make in developing the software, at an architecture level, using proper design and weighing out the realistic possibilities, not the universe thereof. Concretely, if you create a web-based API, then you can put any front-end on it. If you layer the application correctly, you can move some of the layers closer to the client as needed, adding caching for performance. If the problem is one that can only be solved through a desktop application, then the whole question was moot to begin with. I've seen enough Excel-spreadsheets-as-million-dollar-business to know that the only thing standing between you and your completed product is yourself, especially when you have technical skills to actually do the work.
- stcredzero 10y ago
  The risks come from not being able to _easily_ make changes In my experience, this is pretty much the same thing as being unable to change your mind.
  - partisan 10y ago
    If you are a developer and good at what you do, you will layer your application to buffer against changes. If you aren't then just write the code the best you know how because building a business AND learning how to be a good coder at the same time is not the most efficient path. That path is littered with constantly rewritten, half-finished, failures. Get a product out and then figure out where you could have done better.
    - stcredzero 10y ago
      If you are a developer and good at what you do, you will layer your application to buffer against changes. That's a good place to start. That's 80's and 90's best practice, though. (Most of the industry is stuck in this mindset, to be fair.) I'd say the 21st century version of this would be to structure your code in such a way that transformation tools can be easily applied.
      - partisan 10y ago
        So you understand my point.
        stcredzero 10y ago
        The code architecture "win" is always to dodge the big manual rewrite. The "lose" is to have to do the big manual rewrite. People make it into a game of ideological purism, but really, it's as simple and pragmatic as just that. They who dodge the manual rewrite -- those are the real gurus.
        10y ago