Earlier quoted context omitted.
Hmm, I often feel lots of important details or edge cases are only discovered when you start programming. It's a reason waterfall was abandoned. Planning, prototyping and then making a more informed decision is my goto approach, instead of planning forever. Actually, I often feel the architects that think they've "fully solved the problem" are full of themselves, and just not smart enough to realize all the things th…
> It's a reason waterfall was abandoned. Waterfall vs agile is not really about how much effort you put into design, it’s about how long the plan-code-reassess cycle is. You should not plan a whole year ahead and then act, it’s better to plan the next couple of weeks. But you still need to define how the work for those weeks fits in the system, the load it’s expected to take, the metrics that tell you it’s working, h…
Ask HN: Do you hate software engineering but love programming?
391–400 of 733 posts
Re: Ask HN: Do you hate software engineering but love programming?
#392Earlier quoted context omitted.
Agile is made up. The vast majority of places “do it wrong”. Coaches come in and make things even worse, with even less understanding. Saying “they are doing it wrong” and having nothing change isn’t doing anything, and it’s not really a great point. (Not specifically calling you out I just hear this all the time) “Fauxagile” *is* agile, because thats what the majority of places in reality do. “Agile” needs a complet…
Productive teams understand that any "way of working" is just a means to an end, and that good teams find a way to work that suits them (and their situation).
Re: Ask HN: Do you hate software engineering but love programming?
#393The industry is driven by fashion and medium.com-led development.
If you're not jumping on the in-vogue band-wagon then you'll be punished.
After a while you've seen it again and again and you want to avoid it. But that puts you at odds with the industry and employers.
Re: Ask HN: Do you hate software engineering but love programming?
#394I am the exact opposite. I mean, I don’t like processes and meetings, but I do like the planning and architecture part much more than I like actually writing code. Usually, if your mind is decently organized, I find that the problem is solved before writing a single line of code. If that happens, then the actual part of writing becomes dull and mechanical - the problem has already been solved. I’ve never understood p…
Re: Ask HN: Do you hate software engineering but love programming?
#395Re: Ask HN: Do you hate software engineering but love programming?
#396I am the exact opposite. I mean, I don’t like processes and meetings, but I do like the planning and architecture part much more than I like actually writing code. Usually, if your mind is decently organized, I find that the problem is solved before writing a single line of code. If that happens, then the actual part of writing becomes dull and mechanical - the problem has already been solved. I’ve never understood p…
Re: Ask HN: Do you hate software engineering but love programming?
#397Earlier quoted context omitted.
That's fine until half or more of the team moves on, then you have a spaghetti mess that newcomers have to theorize about and clean up.
I'm talking about product design, not technical design. But I don't think specifications help in the long term there, either. I think the way you get designs that are understood by both old-timers and newcomers is continuous improvement of the code through refactoring and cleanup.
Even worse!
Re: Ask HN: Do you hate software engineering but love programming?
#398Earlier quoted context omitted.
Hmm, I often feel lots of important details or edge cases are only discovered when you start programming. It's a reason waterfall was abandoned. Planning, prototyping and then making a more informed decision is my goto approach, instead of planning forever. Actually, I often feel the architects that think they've "fully solved the problem" are full of themselves, and just not smart enough to realize all the things th…
> It's a reason waterfall was abandoned. Waterfall vs agile is not really about how much effort you put into design, it’s about how long the plan-code-reassess cycle is. You should not plan a whole year ahead and then act, it’s better to plan the next couple of weeks. But you still need to define how the work for those weeks fits in the system, the load it’s expected to take, the metrics that tell you it’s working, h…
Read the Manifesto again. You will notice that is actually about the considerations you should take into account if you want to run a software team without managers. Each point is there to ensure that the necessary functions a manager would traditionally take care of still get done.
Waterfall never existed as some kind of formal process. It was invented as an illustrative device.
Re: Ask HN: Do you hate software engineering but love programming?
#399If you haven't read it, I highly recommend A Philosophy of Software Design by John Ousterhout. His talk is a great teaser for the book: https://www.youtube.com/watch?v=bmSAYlu0NcY
Here's the thing: a program properly written for the future does not take longer to get out. Not much, at least. What we instinctively think of as "future proof" is generally anything but: by anticipating some particular kind of change that may happen some time in the future, but in practice almost never does, we end up with more complex programs that are harder to modify when an actual (typically unforeseen) change comes our way.
The best way to future proof your program is to make it simpler, according to the requirement you are currently aware of. If you expect a particular change, sure, plan for it. But for the unexpected, just keep it simple. Because simple is easier to adapt, add to, or rewrite.
That said, the simplest solution is rarely the most obvious. Making thing simple does take a bit more time than rushing through the first thing that comes to mind. But it also pays off in a matter of weeks, so it's quite worth it.
And if you have a hard time assessing what "simple" means, SLoC is a surprisingly good metric (we have research that shows this). And mostly your modules should be deep: small APIs that hide significant implementations. I think of it as encapsulation on steroids.
Re: Ask HN: Do you hate software engineering but love programming?
#400Earlier quoted context omitted.
I read something about how a lot of 'super group' bands kind of don't do anything truly great because of this type of dynamic. They all know they're good, they know the others are good, and they all have a bit of an ego and don't want to stomp on the others, so they all tend to "go along with it" without getting too pushy. That leads to good, but not great music.
Enterprise software is not art and shouldn't be approached the same way. You want a roller-coaster-like experience, go join a startup