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

Sins of software development

blog.ionelmc.ro

Post reply on HN
Print view View original

31–40 of 42 posts

Re: Sins of software development

#31

Post by ilikemustard »

Iftheshoefits wrote: post #21
nawitus wrote: post #20

>Even juniors can have good ideas. I propose that software developers drop this whole idea of "junior developer". There are just developers.

I can see the merit in dropping titles, but not the idea. There are most definitely "junior" developers and "not-junior" developers (call them "senior", "journeyman", "expert" or whatever). Experience is a real, actual thing, and it's reflected in the practice of every industry, including software development.

I completely agree. I've been employed as a software engineer for about 2 months now and I would most definitely consider myself "junior". To put myself on the same level as the people at my place of employment who have been SEs for 20 years would be a disservice to them.

Re: Sins of software development

#32

Post by SheepSlapper »

AndrewKemendo wrote: post #17
lostcolony wrote: post #4

'Most people assume technical debt is there because of time constraints.' As opposed to what? He describes three personality traits, only one of which (hubris; not entirely sure why that's the term used given how close it is to arrogance) actually leads to additional technical debt. Both fear, and arrogance (as he describes it) merely lead to technical debt remaining unaddressed; they don't create it in the first pla…

>I'd posit that technical debt gets created because of time pressure, and that it stays because of continued time pressure I think you could boil everything down to "time pressure" and not have any good insights on a problem. For us our technical debt came in the form of resource constraints, namely not having enough money to hire someone to be able to do a task in the most optimal way. Sure we didn't have years and…

Or how about developer maturity? Looking back at some of the projects I worked on when I was just starting out as a professional developer, I can tell you without a doubt that I introduced technical debt. It wasn't because of time pressures, I had plenty of time, it was simply because I was so green that I didn't know any better.

For example, I built a distributed video transcoding system a few years back, and for the use case at the time it worked great. But let's say people want a new video format? That's a large rewrite. Want to add more servers into the worker pool? That's a large rewrite (the code was written to assume a 1:1 ratio of certain servers, which was dumb).

Basically anything that you might want to change was made harder by the code that I wrote to get the job done initially. Over the years you start to recognize that, and write your code a little smarter and more change tolerant (hopefully introducing less technical debt).

Re: Sins of software development

#33

Post by wellpast »

JoeAltmaier wrote: post #27
wellpast wrote: post #26

By the time technical debt becomes evident enough for it to be noticed as a problem, it is most often too late to do anything about it. For those that don't believe me, show me enough businesses that have successfully refactored their way out of meaningful technical debts. The majority of case studies I know of prove me right on this point. Usually when someone argues to refactor a system, one of two things happen. T…

Good architecture is a windmill. To do that right, you have to know how your requirements will change and grow over time, and put effort into being flexible and extensible in those feature areas. But seeing into the future is risky/imperfect. So code bases are full of clever features and libriaries that are used exactly once. And where rapid growth happened but the code wasn't prepared, sketchy chains of conditions a…

I have to disagree. It doesn't take prescience to build solid architectures. It takes skills.

Prescience (understanding your future requirements) can help dictate what your priorities are as a business, what features and flexibility to deliver today, but it has little to do with architectural soundness, which is simply a property of a system (independent of and not relative to the future).

This is my point -- to argue that a architectural sound choice is too expensive today is right only if the right skills aren't present. This is a problem for our industry to solve.

Re: Sins of software development

#34

Post by nawitus »

Iftheshoefits wrote: post #21
nawitus wrote: post #20

>Even juniors can have good ideas. I propose that software developers drop this whole idea of "junior developer". There are just developers.

I can see the merit in dropping titles, but not the idea. There are most definitely "junior" developers and "not-junior" developers (call them "senior", "journeyman", "expert" or whatever). Experience is a real, actual thing, and it's reflected in the practice of every industry, including software development.

I think experience is greatly overrated. The main reason is that languages and libraries and frameworks change so quickly in software development. How much does 10 years of experience in C++ development help in JavaScript development? It's difficult to say, but someone who has 2 years of JavaScript experience can easily be at the level of someone with 10 years of C++ and 1 year of JavaScript.

Re: Sins of software development

#35

Post by JoeAltmaier »

wellpast wrote: post #33
JoeAltmaier wrote: post #27

Earlier quoted context omitted.

Good architecture is a windmill. To do that right, you have to know how your requirements will change and grow over time, and put effort into being flexible and extensible in those feature areas. But seeing into the future is risky/imperfect. So code bases are full of clever features and libriaries that are used exactly once. And where rapid growth happened but the code wasn't prepared, sketchy chains of conditions a…

I have to disagree. It doesn't take prescience to build solid architectures. It takes skills. Prescience (understanding your future requirements) can help dictate what your priorities are as a business, what features and flexibility to deliver today, but it has little to do with architectural soundness, which is simply a property of a system (independent of and not relative to the future). This is my point -- to argu…

There are so many decisions to make, and they depend upon knowing where you're going. The 'soundness' of the system is a cool property, but it doesn't help make your code nimbler unless the right flexibility is in place. What other purpose is there to architecture?

Re: Sins of software development

#36

Post by Iftheshoefits »

nawitus wrote: post #34
Iftheshoefits wrote: post #21

Earlier quoted context omitted.

I can see the merit in dropping titles, but not the idea. There are most definitely "junior" developers and "not-junior" developers (call them "senior", "journeyman", "expert" or whatever). Experience is a real, actual thing, and it's reflected in the practice of every industry, including software development.

I think experience is greatly overrated. The main reason is that languages and libraries and frameworks change so quickly in software development. How much does 10 years of experience in C++ development help in JavaScript development? It's difficult to say, but someone who has 2 years of JavaScript experience can easily be at the level of someone with 10 years of C++ and 1 year of JavaScript.

It's not really difficult at all to say for somebody who actually has experience: were I time constrained (within reason) I'd take the guy with 10 years of experience over the guy with 2, all other things being equal (e.g. the 2-year guy may be a specialist in a specific use/development case for JavaScript, or the time constraint might be very restrictive, to the point that the day or week the 10-year person might need to come up to speed isn't available).

Experience is not necessarily a big factor, and what qualifies as "experience" is highly dependent on context. However, the experienced person generally has just seen more than the inexperienced person. They've had a chance to deal with stuff the inexperienced person just hasn't. That counts for something; in some (most?) cases, quite a lot. It's a bit silly to dismiss experience out of hand, or to minimize the role it plays.

Also, "languages and libraries and frameworks" don't really change all that often in practice, in most places where software has been employed as a solution. That's a very "Web Dev is All Software Dev" (read: myopic) Valley-centric belief. You're referring to very narrow, niche instances where startups "pivot" frequently (or can't make up their mind, or are run by fad-chasing hipsters).

Re: Sins of software development

#37

Post by ownedthx »

We follow a simple rule about technical debt:

If you are working on an issue, and technical debt is affecting your ability to create factored, testable code, then fix the debt.

It might mean a 1 hour issue takes 4 hours, or more. But we put a premium on writing tested code, such that we can push builds often to production.

However, we never make a task ' go fix technical debt X'.

That way, you don't waste time on something that really isn't a problem.

It's working for us well, so far.

Re: Sins of software development

#38

Post by lostcolony »

AndrewKemendo wrote: post #17
lostcolony wrote: post #4

'Most people assume technical debt is there because of time constraints.' As opposed to what? He describes three personality traits, only one of which (hubris; not entirely sure why that's the term used given how close it is to arrogance) actually leads to additional technical debt. Both fear, and arrogance (as he describes it) merely lead to technical debt remaining unaddressed; they don't create it in the first pla…

>I'd posit that technical debt gets created because of time pressure, and that it stays because of continued time pressure I think you could boil everything down to "time pressure" and not have any good insights on a problem. For us our technical debt came in the form of resource constraints, namely not having enough money to hire someone to be able to do a task in the most optimal way. Sure we didn't have years and…

Yeah, my point wasn't that you can't drive deeper into the problem and come up with something more specific, but that the statement this article leads with (''Most people assume technical debt is there because of time constraints') is misleading. Of course people assume that, because most of the time it's true.

Re: Sins of software development

#39

Post by lostcolony »

JoeAltmaier wrote: post #27
wellpast wrote: post #26

By the time technical debt becomes evident enough for it to be noticed as a problem, it is most often too late to do anything about it. For those that don't believe me, show me enough businesses that have successfully refactored their way out of meaningful technical debts. The majority of case studies I know of prove me right on this point. Usually when someone argues to refactor a system, one of two things happen. T…

Good architecture is a windmill. To do that right, you have to know how your requirements will change and grow over time, and put effort into being flexible and extensible in those feature areas. But seeing into the future is risky/imperfect. So code bases are full of clever features and libriaries that are used exactly once. And where rapid growth happened but the code wasn't prepared, sketchy chains of conditions a…

Good architecture is a windmill? Something you tilt at, I'm guessing? Not heard a direct analogy like that.

Re: Sins of software development

#40

Post by wellpast »

JoeAltmaier wrote: post #35
wellpast wrote: post #33

Earlier quoted context omitted.

I have to disagree. It doesn't take prescience to build solid architectures. It takes skills. Prescience (understanding your future requirements) can help dictate what your priorities are as a business, what features and flexibility to deliver today, but it has little to do with architectural soundness, which is simply a property of a system (independent of and not relative to the future). This is my point -- to argu…

There are so many decisions to make, and they depend upon knowing where you're going. The 'soundness' of the system is a cool property, but it doesn't help make your code nimbler unless the right flexibility is in place. What other purpose is there to architecture?

Architectural flexibility and architectural soundness are orthogonal properties. An inflexible system that is architecturally sound may obligate you to build more than its more flexible counterpart when novel use cases come around but it allows you to build more when these use cases come. An architecturally unsound system makes it prohibitively expensive to solve future use cases.

So the purpose of architecture, I'd say, is to first ensure soundness (which should cost no more than building an unsound system so long as you have the right skill set) and only then strike the right level of flexibility in the architecture (another, separate skill set that is valuable but less of a current industry problem, imo).

You can evolve the flexibility of a sound architecture but you can't do much with an unsound one. Inflexiblity in a system is generally a tractable "problem". Unsoundness is not (unwinding coupling, eg, is rarely tractable.)

Post reply on HN