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

How to Design Software Good

haiku-os.org

Post reply on HN
Print view View original

151–160 of 191 posts

Re: How to Design Software Good

#151

Post by laythea »

hailk wrote: post #131
laythea wrote: post #115

Earlier quoted context omitted.

There is a very real truth to what you say, and I don't believe it is bad. We don't want golden-polished software. Software that only just does its job, makes the company money, pays the bills, and allows for future improvements where possible/necessary. Lean and mean, then refine (if the bills have been paid). The distinction has to be made between good software and well-written software. It is very possible to have…

For a long time, I kept pushing deadlines because I wanted to write things the "right way". At the end a code that doesn't reach its destination on time or doesn't do what it should be doing is useless, no matter how well written. A good engineer knows when to obsess over code quality and when to look the other way.

Agree. It helps to cut your software-chops or steer yourself into an industry where software is an overhead, rather than the main product (said in the best possible manner).

For example, controller software attached to a turbine engine. What I said above is especially true in those scenarios and is actually quite folly to do more than necessary in the name of software perfection. Plus unnecessary complication hurts brains :)

Re: How to Design Software Good

#152

Post by skohan »

ensiferum wrote: post #144
skohan wrote: post #134

Earlier quoted context omitted.

I'm not saying clean code is not desirable. Code which is easy to maintain and modify is absolutely better than messy code. My point is that "good code" should be prioritized behind a good product. The purpose of code is to deliver a product, not to be well-factored or to embody certain principals. If your product is bad, your code is already categorically bad, no matter how beautiful it is.

But it's really difficult to make a good product and good product experience on a messy code base. Quality code leads to better product IMHO. (of course good quality code base can still suffer from badly designed UX)

The devil is in the details. Sure, if your codebase is systemically messy, it's probably going to take forever to get anything done, and you will probably end up with bugs in the final product.

But what if you have a component here or there with well defined, well tested interfaces, but internally it's a bit of a mess? Or what if you hack together a proof-of-concept for a new feature to get it out the door and see what users do with it before investing a lot of time in making it perfect? Those kinds of things can help your organization move faster.

As with most things, clean vs messy code is not a binary. It's the sum of a lot of individual value judgements about when it's pragmatic to focus on code quality.

Re: How to Design Software Good

#153

Post by CathyWest »

collyw wrote: post #125
bengale wrote: post #85

Earlier quoted context omitted.

Pretty much my experience too. I don't think it's ever been worth the time or effort to spend time on writing quality software, the people that smash it out quickly are the ones rewarded. I'm starting to feel like the whole movement for 'software craftsmanship' is making a lot of developers miserable. It's maybe better for them to realise they are not artisans, they are bricklayers. To focus that creative energy on t…

>I'm starting to feel like the whole movement for 'software craftsmanship' is making a lot of developers miserable. Not as miserable as working on some 7 year old system hacked together without any craftsmanship. Plus if its a long term project the maintenance costs must spiral.

I think the point is that it's better to work on some 7 year old system hacked together without any craftsmanship with the belief that craftsmanship is nonsense and spaghetti code is a legitimate design pattern, than to work on it knowing there is a better way to design software.

Re: How to Design Software Good

#154

Post by dasil003 »

lou1306 wrote: post #129
skohan wrote: post #107

Earlier quoted context omitted.

> Clean code doesn't mean "no bugs" and "good software" This gets missed too often: clean interfaces are important, whether it's a UI or an API. Clean code? It depends. I once interviewed a dev who had all the right answers when it came to software development practices, TDD, etc, but when we looked at the product he was working on, the UX was a stuttering mess. I don't care what your code looks like if you did not a…

> the UX was a stuttering mess. Is that a good metric to judge a developer, though? Good UX requires either formal training in the field, or a very gifted individual. In my opinion it has very little to do with the quality of either the code or the developer.

Not necessarily, but good developers need to be thinking about their upstreams and downstreams. This is often uncomfortable because a developer personality often wants to know all the minute details and not have to worry about areas outside their core competence, but you can't build large scale software without at least a critical mass of developers thinking big picture. UX in particular depends on the task at hand, but if it's a consumer product and you're working fairly close to the surface (client or API tier) then yeah I'd expect some awareness of UX.

Re: How to Design Software Good

#155

Post by philangist »

lucio wrote: post #145
xgbi wrote: post #90

Earlier quoted context omitted.

Disclosure: small-ish company (~100 employees) in France You know, I kind of went through the same questioning: at my current company we have an employee that has his niche/historical role on one of the key infrastructure of our product. The guys works from his home and whatever hours, commits 300+ lines per commit (90% of which is unrelated to the commit name, just commenting things or uncommenting others). The code…

I bet the cost/benefit for the company is positive, and as long the clients are happy and paying, how this guy works is irrelevant. he was rewriting a huffman compression algorithm by himself because he's bored and he wants to learn and experiment. I bet is not a good life he's living. There's a great disorder in working from your home at odd hours, it's not healthy. He would be happier working normal, fixed hours, a…

> There's a great disorder in working from your home at odd hours, it's not healthy

I'd be curious in hearing you elaborate on this. I've been in a WFH setup like this for about 4 months, and while I enjoy it right now I do wonder if it'll be something I might regret after 2-3 years on this schedule.

My primary reasons for working like this are that: 1. I hate being in the corporate office environment, it feels very artificial and constraining 2. I tend to have my most productive coding sessions very late at night anyway

Re: How to Design Software Good

#156

Post by dionidium »

bjoli wrote: post #79
mafro wrote: post #57

Earlier quoted context omitted.

Once upon a time, the whole internet was going to be built this way!

I still think client side XSLT is a good thing. I write simple documents and it is automatically converted client side. The world's best static site generator. I gives me the best of two worlds: simple markup with complete control of output and CSS styling and instant changes of all documents without a compilation step.

XSLT got an unfair shake. Yes, XML is ugly, and verbose, and painful to write code in, but the ideas were very good. Most users never understood the processing model or the declarative/functional nature of XSLT, and so tried to write procedural code with it, with predictably nasty outcomes (hint: is almost always a code smell). But those who did get it, could use it to write some pretty elegant little programs.

Re: How to Design Software Good

#157

Post by dionidium »

AznHisoka wrote: post #130
Antoninus wrote: post #83

Earlier quoted context omitted.

Maybe its meant to be tongue-in-cheek.

Thats how I interpreted it. Sort of like when people say happy christmas instead of merry.

"Happy Christmas" isn't tongue in cheek. It's just literally what people in England actually say.

Re: How to Design Software Good

#158

Post by noir_lord »

xgbi wrote: post #90
CathyWest wrote: post #80

> Writing good software can be hard, but it is worth the time and effort. Is it? I want this to be true because I want to write good software. But I've worked with some very senior developers who would disregard all software engineering and user experience concerns and just spew large quantities of low-quality code that made the managers just as happy, especially since it got done quickly. And the end-users in many n…

Disclosure: small-ish company (~100 employees) in France You know, I kind of went through the same questioning: at my current company we have an employee that has his niche/historical role on one of the key infrastructure of our product. The guys works from his home and whatever hours, commits 300+ lines per commit (90% of which is unrelated to the commit name, just commenting things or uncommenting others). The code…

I replaced that guy at my company (similar size) and a year in I'm barely scratching the surface of the horror, a lot of the time I end up putting a safe interface in front of it and a big note saying fix this at some point.

It's nor even that the code is bad (and it is) it's that he couldn't think straight, the business logic is all insane as well.

Still boss hired me to sort it out and the time scale is measured in years (week is a mix of new stuff and fixing old stuff).

Typical performance improvement is two orders of magnitude.

When I started it took 70s to search for a quote.

Now it takes 200ms and mine includes the line details on the quote in a easy to eyeball format.

My boss seems happy at least.

Re: How to Design Software Good

#159

Post by noir_lord »

donquichotte wrote: post #146
xgbi wrote: post #90

Earlier quoted context omitted.

Disclosure: small-ish company (~100 employees) in France You know, I kind of went through the same questioning: at my current company we have an employee that has his niche/historical role on one of the key infrastructure of our product. The guys works from his home and whatever hours, commits 300+ lines per commit (90% of which is unrelated to the commit name, just commenting things or uncommenting others). The code…

Beautiful! I would pay for a book with more anectotes of kafkaesque, nightmarish visions of horrendous programs.

I could spend a year writing blog posts on the one I inherited :)

Re: How to Design Software Good

#160

Post by crististm »

joe_fishfish wrote: post #112
MaxBarraclough wrote: post #103

Earlier quoted context omitted.

I'm reminded of, of all things, WW2 tanks. The Russians built a huge volume of very low-quality tanks, expected to go for only a few hundred miles, and to win through superior numbers. Their crews were poorly trained. The designers suggested easy-win improvements, but the brass blocked the changes as it would have impacted production rates. The Germans built the best-engineered tank the world had ever seen, but its d…

Worse is better.

"worse is better" is worse
Post reply on HN