6 ms·

Looks lovely, but I wish people would focus less on fast development and more on something that better maintainability 2 years down the road. When it comes to

Looks lovely, but I wish people would focus less on fast development and more on something that better maintainability 2 years down the road. When it comes to the lifecycle of most applications, the speed of developing something new has a marginal impact on the overall costs, and most tools and frameworks than enable rapid initial development tend to suck once you have a big app on top of them. This is why we fawn over a tool when it's shiny and new, and bitch about how much it sucks 3 to 5 years later.

mydoghasworms 14y ago
You are very right in saying this, but I would have to contend that there is a large scope for quick-to-market apps and small, simple-purpose apps. In addition to that, it seems that many apps created today themselves have a limited lifespan, after which they are replaced by something else (though you can never tell upfront). The other side of the coin is building something with the intent of maintaining it for many years, only to find it is obsolete within 2. (Meaning that the "right tool for the job" cannot always be determined correctly in software development).
wodow 14y ago
> ... the speed of developing something new has a marginal impact on the overall costs But it has a large impact on the overall probability of getting off the ground at all - and this is what most projects (and people) never do.
- gbog 14y ago
  > [dev speed has] a large impact on the overall probability of getting off the ground I don't know. This seems common sense but it could be a cliché too. If we look at other domains, it is not always true. For instance, if you write novels that are not tied to some evanescent trend like a pop star's private life, then the chance of getting off the ground if not directly linked to the timing of publication. It would be the same if you are creating a newly designed chair. Even on the web, let's take two success stories: when Wikipedia or Twitter were created and made public, I don't remember seeing five other contenders running behind them, and being only two-features-months behind. Same with, say, Minecraft. I am all for quick development, because it is more fun, but not because it would magically increase to probability of success, which is too low to compute and unpredictable anyway. I am also all for choosing carefully which path you take, especially when you cross virgin territories. You don't want to find yourself spending a night half naked with a toothpick for your sole defense in Borneo's jungle.
  - wodow 14y ago
    I'm not sure about the novel and chair examples, but the issue of evidence of every early stage failures in general is interesting. The other proto-pedias and Minecraft-could-have-beens never happened at all - for some people, they stayed on the drawing board and never made it to the web - so there's no evidence of them to point to at all. They left no trace.
  - gr2m 14y ago
    Let's say today 1 of 1000 people is able to create an app to solve a problem, let's say time time tracking. Now imagine we change that drastically, to 100 of 1000 or even more. People will start to build their own little apps to solve their own little problems. And if these break, nobody cares, but them. For example, friends of mine like to go climbing. They've build an app in an afternoon, just for their group, to keep track of what tracks they finished and how they liked it. I think this is fascinating. I wonder what would happen if students would learn to build simple apps like that in school, instead of Excel?
    - lkrubner 14y ago
      "Now imagine we change that drastically, to 100 of 1000 or even more. People will start to build their own little apps to solve their own little problems. And if these break, nobody cares, but them." This was the old dream of Hypercard, and it worked very well for a long time. http://en.wikipedia.org/wiki/HyperCard http://en.wikipedia.org/wiki/HyperCard Both Danny Goodman and Bill Atkinson have stated publicly that they got programming questions from every kind of person: small business owners, school teachers, ski bums, taxi drivers, etc. Hypercard let non-programmers build simple apps, and so a lot of apps were created that would never have been created if app-creation was left in the hands of professional programmers. And many of those little apps were tailored to what the creator needed at that moment, in a way that could never happen if a professional programmer drew up some spec.
      - deleted 14y ago
        [deleted]
      - 14y ago
rektide 14y ago
I wish people would focus less on fast development and more on something that better maintainability 2 years down the road. Hoodie focuses on the data model, not the application logic or UI. If there's one thing I want to be consistent and maintainable and to have a really solid support stack under it- if there's one area I value maintainability and consistency- it's the data layer, which this very much attempts to provide a consistent development experience for. An app built with hoodie I could see as being maintainable- even as you gut the entire stack and drag your rails app to flask, or your php app to java, hoodie has defined only the kinds of objects and patterns of accessing them that you'll reuse in whatever your actual app stack is. Hoodie targets the data, which is the thing. Everything else? Who cares. Here's to maintainable data.

mydoghasworms 14y ago

You are very right in saying this, but I would have to contend that there is a large scope for quick-to-market apps and small, simple-purpose apps. In addition to that, it seems that many apps created today themselves have a limited lifespan, after which they are replaced by something else (though you can never tell upfront). The other side of the coin is building something with the intent of maintaining it for many years, only to find it is obsolete within 2. (Meaning that the "right tool for the job" cannot always be determined correctly in software development).

wodow 14y ago

> ... the speed of developing something new has a marginal impact on the overall costs But it has a large impact on the overall probability of getting off the ground at all - and this is what most projects (and people) never do.

gbog 14y ago
> [dev speed has] a large impact on the overall probability of getting off the ground I don't know. This seems common sense but it could be a cliché too. If we look at other domains, it is not always true. For instance, if you write novels that are not tied to some evanescent trend like a pop star's private life, then the chance of getting off the ground if not directly linked to the timing of publication. It would be the same if you are creating a newly designed chair. Even on the web, let's take two success stories: when Wikipedia or Twitter were created and made public, I don't remember seeing five other contenders running behind them, and being only two-features-months behind. Same with, say, Minecraft. I am all for quick development, because it is more fun, but not because it would magically increase to probability of success, which is too low to compute and unpredictable anyway. I am also all for choosing carefully which path you take, especially when you cross virgin territories. You don't want to find yourself spending a night half naked with a toothpick for your sole defense in Borneo's jungle.
- wodow 14y ago
  I'm not sure about the novel and chair examples, but the issue of evidence of every early stage failures in general is interesting. The other proto-pedias and Minecraft-could-have-beens never happened at all - for some people, they stayed on the drawing board and never made it to the web - so there's no evidence of them to point to at all. They left no trace.
- gr2m 14y ago
  Let's say today 1 of 1000 people is able to create an app to solve a problem, let's say time time tracking. Now imagine we change that drastically, to 100 of 1000 or even more. People will start to build their own little apps to solve their own little problems. And if these break, nobody cares, but them. For example, friends of mine like to go climbing. They've build an app in an afternoon, just for their group, to keep track of what tracks they finished and how they liked it. I think this is fascinating. I wonder what would happen if students would learn to build simple apps like that in school, instead of Excel?
  - lkrubner 14y ago
    "Now imagine we change that drastically, to 100 of 1000 or even more. People will start to build their own little apps to solve their own little problems. And if these break, nobody cares, but them." This was the old dream of Hypercard, and it worked very well for a long time. http://en.wikipedia.org/wiki/HyperCard http://en.wikipedia.org/wiki/HyperCard Both Danny Goodman and Bill Atkinson have stated publicly that they got programming questions from every kind of person: small business owners, school teachers, ski bums, taxi drivers, etc. Hypercard let non-programmers build simple apps, and so a lot of apps were created that would never have been created if app-creation was left in the hands of professional programmers. And many of those little apps were tailored to what the creator needed at that moment, in a way that could never happen if a professional programmer drew up some spec.
    - deleted 14y ago
      [deleted]
    - 14y ago

rektide 14y ago

I wish people would focus less on fast development and more on something that better maintainability 2 years down the road. Hoodie focuses on the data model, not the application logic or UI. If there's one thing I want to be consistent and maintainable and to have a really solid support stack under it- if there's one area I value maintainability and consistency- it's the data layer, which this very much attempts to provide a consistent development experience for. An app built with hoodie I could see as being maintainable- even as you gut the entire stack and drag your rails app to flask, or your php app to java, hoodie has defined only the kinds of objects and patterns of accessing them that you'll reuse in whatever your actual app stack is. Hoodie targets the data, which is the thing. Everything else? Who cares. Here's to maintainable data.