6 ms·

"And we're still hitting up against major unknowns all the time at every level of the practice, big and small." I was with you until you got to this line. Let

by timr 13y ago

"And we're still hitting up against major unknowns all the time at every level of the practice, big and small." I was with you until you got to this line. Let's be brutally honest: the limiting factor for most of today's software projects (i.e. CRUD websites and iPhone apps) is not technology. It's developer competency, experience and self-discipline. I'd go so far to say that most working software developers don't even understand the fundamentals of the technologies they're using -- it's why you see people replacing their relational databases for key-value stores, then trying to re-invent database join algorithms from scratch in the application layer. Or why every new generation of "engineers" re-discovers asynchronous programming in a new language (then promptly writes a framework in Blub...because Blub is so much better than last year's Blub.) Truthfully, it's pretty damned hard to find gigs working on the frontier of technology. Most projects are predictable, tedious slogs to fit together well-understood technologies without shooting yourself in the foot. And yes, requirements shift and clients get fussy, but that's true of any engineering discipline. You learn to pad the schedule to compensate for the shifts. It's part of being a professional. As far as I can see, commercial software isn't limited by "major unknowns", so much as an industry-wide unwillingness to learn from experience. But hey...that tends to happen in industries when you're considered "old" at 30....

hackula1 13y ago
Granted, most engineers are not exactly employing quantum physics to parking lot design. Most people, in general, work on gluing together pre-built parts that they do not understand all of the fundamentals of.
Widdershin 13y ago
Ah man, this hit slightly hard as someone who just moved from Postgres to MongoDB to avoid database migrations only to realize that I've now lost the power of a many to many relationship.
- deleted 13y ago
  [deleted]
- voltagex_ 13y ago
  Wouldn't you look for better migration tooling rather than jumping technology?
  - Widdershin 13y ago
    As far as I know, the best migration tool for SQLAlchemy is Alembic, and it can't magically handle migrations (which is what I wanted). I jumped technology because it seemed like MongoDB did (and still does) meet my use case better. I'm open to any opinions or advice though.
- deleted 13y ago
  [deleted]
- yen223 13y ago
  How would one avoid database migrations by switching databases?
  - Widdershin 13y ago
    MongoDB is schemaless, so you don't have to do traditional migrations. Unless you're making a joke about me migrating to a different database to avoid migrations, in which case, good joke.
    - morphyn 13y ago
      Migrations are about data, not schema. You don't need migrations with a "schemaless" database at the beginning, but as soon as you have data you care about, you're gonna need to ensure some sort of consistency.
      - Widdershin 13y ago
        Do you think I should move back to Postgres? If so, why? Genuinely looking for well backed technically minded opinions here.
        paddy_m 13y ago
        I think you should learn the relational model (not SQL). Understand the problems it was trying to solve and how the relational model solves them. Then figure out how that applies to your app. Database in Depth was helpful for me http://www.amazon.com/Database-Depth-Relational-Theory-Practitioners/dp/0596100124 http://www.amazon.com/Database-Depth-Relational-Theory-Pract... .
        vinceguidry 13y ago
        Yes, you should move back to Postgres. The reason is you can do many more operations on structured data than on structure-less data. You found that out already with the many-to-many thing. There are plenty of other intangibles that will bite you in the ass later.
    - 13y ago
trimbo 13y ago
> As far as I can see, commercial software isn't limited by "major unknowns" I'm sorry, I needed to get in an afternoon run and actually deleted a paragraph that explained this a little more that I couldn't get just right before posting. I completely agree with you. There aren't a lot of technical unknowns for most things people are trying to do. Thing is, I wasn't actually talking about technical challenges with that point, rather, the requirements that are given at the beginning of a project. The requirements for the new Bay Bridge, for example, are pretty darn clear: make a new bridge from Oakland to Yerba Buena Island. The requirements for making G+ attract Facebook users... errr... uhh... Or how about the requirements for the next Call of Duty to be fun... A great many of today's software projects -- especially those discussed here on HN -- aren't straight up engineering problems, they're more design and UX problems. Even for something like the software for the Joint Strike Fighter, you're more into UX than hard-hittin' avionics for a lot of it these days. And I think that's what makes it hard to predict software development schedules. If we were all building ATM software again and again, we'd be knocking it out of the park. A competitor to Snapchat that is able to sway users over... that might be harder to define up front.

by timr 13y ago

hackula1 13y ago

Granted, most engineers are not exactly employing quantum physics to parking lot design. Most people, in general, work on gluing together pre-built parts that they do not understand all of the fundamentals of.

Widdershin 13y ago

Ah man, this hit slightly hard as someone who just moved from Postgres to MongoDB to avoid database migrations only to realize that I've now lost the power of a many to many relationship.

deleted 13y ago
[deleted]
voltagex_ 13y ago
Wouldn't you look for better migration tooling rather than jumping technology?
- Widdershin 13y ago
  As far as I know, the best migration tool for SQLAlchemy is Alembic, and it can't magically handle migrations (which is what I wanted). I jumped technology because it seemed like MongoDB did (and still does) meet my use case better. I'm open to any opinions or advice though.
deleted 13y ago
[deleted]
yen223 13y ago
How would one avoid database migrations by switching databases?
- Widdershin 13y ago
  MongoDB is schemaless, so you don't have to do traditional migrations. Unless you're making a joke about me migrating to a different database to avoid migrations, in which case, good joke.
  - morphyn 13y ago
    Migrations are about data, not schema. You don't need migrations with a "schemaless" database at the beginning, but as soon as you have data you care about, you're gonna need to ensure some sort of consistency.
    - Widdershin 13y ago
      Do you think I should move back to Postgres? If so, why? Genuinely looking for well backed technically minded opinions here.
      - paddy_m 13y ago
        I think you should learn the relational model (not SQL). Understand the problems it was trying to solve and how the relational model solves them. Then figure out how that applies to your app. Database in Depth was helpful for me http://www.amazon.com/Database-Depth-Relational-Theory-Practitioners/dp/0596100124 http://www.amazon.com/Database-Depth-Relational-Theory-Pract... .
      - vinceguidry 13y ago
        Yes, you should move back to Postgres. The reason is you can do many more operations on structured data than on structure-less data. You found that out already with the many-to-many thing. There are plenty of other intangibles that will bite you in the ass later.
  - 13y ago

trimbo 13y ago

> As far as I can see, commercial software isn't limited by "major unknowns" I'm sorry, I needed to get in an afternoon run and actually deleted a paragraph that explained this a little more that I couldn't get just right before posting. I completely agree with you. There aren't a lot of technical unknowns for most things people are trying to do. Thing is, I wasn't actually talking about technical challenges with that point, rather, the requirements that are given at the beginning of a project. The requirements for the new Bay Bridge, for example, are pretty darn clear: make a new bridge from Oakland to Yerba Buena Island. The requirements for making G+ attract Facebook users... errr... uhh... Or how about the requirements for the next Call of Duty to be fun... A great many of today's software projects -- especially those discussed here on HN -- aren't straight up engineering problems, they're more design and UX problems. Even for something like the software for the Joint Strike Fighter, you're more into UX than hard-hittin' avionics for a lot of it these days. And I think that's what makes it hard to predict software development schedules. If we were all building ATM software again and again, we'd be knocking it out of the park. A competitor to Snapchat that is able to sway users over... that might be harder to define up front.