Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Are we overcomplicating software development?

news.ycombinator.com

Post reply on HN
Print view View original

351–360 of 378 posts

Re: Ask HN: Are we overcomplicating software development?

#351

Post by peruvian »

eikenberry wrote: post #308
SatvikBeri wrote: post #196

Earlier quoted context omitted.

In our case, we did that using functional programming & type-driven design (which ironically is also a TDD.)

T(est)DD does tend to make your code look more like you used a functional-oriented language. A lot less mutability, heavier use of first-class functions, etc. Though I tend to prefer languages that are at least somewhat functional (eg. python, go).

> Though I tend to prefer languages that are at least somewhat functional (eg. python, go).

Can't think of any less functional languages than these.

Re: Ask HN: Are we overcomplicating software development?

#352

Post by cookiecaper »

brwr wrote: post #197
cookiecaper wrote: post #159

Earlier quoted context omitted.

Employees and management don't buy into it for the same reason that consultants don't buy into it. It means less work. Less opportunity to sound smart, seize control, and/or ego stroke. Less variety to break up the work-week's monotony.

Ego is one of the larger problems I've seen over the years. This usually shows, as you mention, with someone trying to sound smart. The irony here is that I've consistently found -- both inside and outside the software industry -- that the smartest people in the room are the ones who can speak about complex topics in a simple way.

It's a dilemma, because "it takes one to know one". While a few smart people in the workplace may be able to appreciate a brilliant dilution of an extremely complex topic into something approachable, most will not understand the starting complexity and just assume it's an approachable topic.

This is fine and everything, but it's bad self-promotion. If you want your bosses to give you a raise, you need them to think that you have a unique, difficult-to-acquire skillset and that it's worth going to lengths to keep you happy.

Unfortunately, modest behavior rarely results in recognition. Bombast is a very effective tool, and at some level, you always have to compete against someone.

Re: Ask HN: Are we overcomplicating software development?

#353

Post by ChuckMcM »

akamaozu wrote: post #344
ChuckMcM wrote: post #96

Yes we are over complicating it, but that it primarily about trying to take what is essentially an artistic process and turning it into a regimented process (a known hard problem). Rob Gingell at Sun stated it as a form of uncertainty principal. He said, "You can know what features are in a release or when the release will ship, but not both." It captured the challenge of aspirational feature development where someon…

Link to the post about the graphics library please?

https://news.ycombinator.com/item?id=13419665

Re: Ask HN: Are we overcomplicating software development?

#354

Post by EdHominem »

eklavya wrote: post #305
EdHominem wrote: post #262

Earlier quoted context omitted.

I hear this data-integrity thing a lot but I don't run into these problems myself. I think it might be a functional-programming thing. It's much easier and safer to declare your constraints rather than trying to enforce them. If you aren't in a functional language I can see why you'd want to reach out to one but SQL in a separate process is just one of the options. > Things such as joins, transactions, and means of e…

STM is awesome but a single node solution. Distributed transactions are a hard problem.

I understand, but you can't just throw a DB at it and walk away. For instance, which DB? Setup how? Running on what type of hosts? What topological requirements does this have? How much does of a multiplier does it place on your data load.

I'd definitely use a trusted DB for storing bank accounts. The consistency is pretty much the first requirement and the data maps perfectly to tables. And 7B checking accounts isn't that big, compared to some problems so it'd probably scale pretty well even worst-case.

But I probably wouldn't for an MMO. Or at least, it wouldn't be where I stored every little thing going on around them - just the events (xp and gold earned) that they'd freak out about if we lost. But even just a log-structured DB would work well for that.

If there's no contention for a resource (in the bank case - the value in the account) there's much less reason for a transaction. I want the system to make its best effort but I don't want to wait around for the message if there isn't anything I can do on a failure anyways.

Re: Ask HN: Are we overcomplicating software development?

#355

Post by gmarx »

iainmerrick wrote: post #55
reacharavindh wrote: post #31

Earlier quoted context omitted.

> Agile methods are also useful. If you can't plan 2 weeks of work you can probably not plan 6 months. Hmmm. I was just thinking the opposite yesterday. I'm a performance engineer working closely with two teams. One doing Agile and the other basing on wikis and Adhoc in-person whiteboard discussions. I find the non agile team more productive, efficient and dare I say happy. The Agile based team makes me sit in on the…

One doing Agile and the other basing on wikis and Adhoc in-person whiteboard discussions. The ad-hoc approach also sounds quite agile (at least with a small 'a'). It's certainly closer to Agile than to Waterfall, assuming they didn't do a big design up front before writing any code. I think the ad-hoc agile approach can work very well with a good team. But Scrum fans always seem to warn against cherry-picking just th…

Depends what you cherry pick. One of the key assumptions of Scrum is colocated teams and (implicitly) engineers who want to understand and think creatively about the domain problems. Without those you have my personal guarantee you will fail

Re: Ask HN: Are we overcomplicating software development?

#356

Post by spdionis »

flukus wrote: post #269
TeMPOraL wrote: post #214

Earlier quoted context omitted.

> In my opinion dumping an ORM on top is also not the best way to leverage the strengths of an RDBM. I agree. Unfortunately, the way I see people usually using them is pretty bad - you should not let ORM-generated stuff dictate your business model. Database is a database. A storage layer. Business objects will not map 1:1 to ORM objects. Approaches like "let's inherit from ORM class and add business-related methods",…

> Approaches like "let's inherit from ORM class and add business-related methods", in my experience, lead to total disaster. I don't disagree, in fact I'd go further and say that data and logic should not be coupled, but this is the Active record pattern which is far from the only way to use an ORM, most ORM's won't even support this pattern by default.

Moreover this is a terrible pattern. I would never use an ORM like that. An ORM implemented using the DataMapper pattern is so much better.

Re: Ask HN: Are we overcomplicating software development?

#357

Post by brwr »

cookiecaper wrote: post #352
brwr wrote: post #197

Earlier quoted context omitted.

Ego is one of the larger problems I've seen over the years. This usually shows, as you mention, with someone trying to sound smart. The irony here is that I've consistently found -- both inside and outside the software industry -- that the smartest people in the room are the ones who can speak about complex topics in a simple way.

It's a dilemma, because "it takes one to know one". While a few smart people in the workplace may be able to appreciate a brilliant dilution of an extremely complex topic into something approachable, most will not understand the starting complexity and just assume it's an approachable topic. This is fine and everything, but it's bad self-promotion. If you want your bosses to give you a raise, you need them to think t…

Well, it depends. I personally don't feel the need to self-promote to get a raise. I'll probably lose out on a few raises or promotions because of that, but I make a good amount of money and I'm good at what I do. That's enough for me.

Re: Ask HN: Are we overcomplicating software development?

#358

Post by eikenberry »

peruvian wrote: post #351
eikenberry wrote: post #308

Earlier quoted context omitted.

T(est)DD does tend to make your code look more like you used a functional-oriented language. A lot less mutability, heavier use of first-class functions, etc. Though I tend to prefer languages that are at least somewhat functional (eg. python, go).

> Though I tend to prefer languages that are at least somewhat functional (eg. python, go). Can't think of any less functional languages than these.

Think of the language features you need to be able to program in a functional way, then think about what these languages have. There is a sizable overlap.

If you need a template then think of scheme. It is the best example of a minimal functional language.

Re: Ask HN: Are we overcomplicating software development?

#359

Post by dcminter »

ci5er wrote: post #261
dcminter wrote: post #121

Earlier quoted context omitted.

I was once on a project where an "agile" team, at the behest of their managers, held a sprint "to improve velocity." I kid you not. I will add that I was not on that team. Our scrum master, who was excellent, shielded us entirely from the management madness.

What was the idea behind this? Spending some dedicated time knocking through some accumulated crud? (I think people call it 'technical debt' these days). Is that a bad thing?

Nope. That I could have respected and would have made some sense. It was code for "the team will work longer hours and over the weekend so that an arbitrary number is higher."

Re: Ask HN: Are we overcomplicating software development?

#360

Post by ci5er »

dcminter wrote: post #359
ci5er wrote: post #261

Earlier quoted context omitted.

What was the idea behind this? Spending some dedicated time knocking through some accumulated crud? (I think people call it 'technical debt' these days). Is that a bad thing?

Nope. That I could have respected and would have made some sense. It was code for "the team will work longer hours and over the weekend so that an arbitrary number is higher."

Hmmm. Weird. That sounds like people trying to engage in "growth hacking". I wonder if someone's bonus was tied to it.

If they were really serious about "velocity" (for whatever reason; some are legit), they'd divide by man-hours, not weeks, anyway, and have actuals going back 3+ months (6+ is better) to baseline their sitrep before they started knob-twiddling.

Post reply on HN