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

You can't design software you don't work on

seangoedecke.com

Post reply on HN
Print view View original

101–110 of 119 posts

Re: You can't design software you don't work on

#101

Post by augustk »

roguecoder wrote: post #53
augustk wrote: post #11

In the best scenario the developers are also active users of the software they produce. Then a design flaw or an error that affects the users will also affect the developers and will (hopefully) motivate the latter to correct it.

XP putting a customer on the team was the best thing in the methodology. Replacing those with business representatives is one of Scrum's original sins.

It's also worth noting that a customer is not necessarily a user. As a developer I don't care so much about the customer but I care wholeheartedly about the users.

Re: You can't design software you don't work on

#102

Post by whstl »

RaftPeople wrote: post #99
whstl wrote: post #80

Earlier quoted context omitted.

Once again, that's only true at the surface level. If you dig deeper you'll realize that it's possible to categorize techniques, tools, libraries, algorithms, recipes, whatever. And if you dig even deeper, you'll realize that there is foundational knowledge that lets you understand a lot of things that people complain about being too new. The biggest curse of software is people saying "no" to education and knowledge.

> Once again, that's only true at the surface level. Can you provide concrete examples of the things that you think are foundational in software? I'm thinking beyond "be organized so it's easier for someone to understand", which applies to just about everything we do (e.g. modularity, naming, etc.) For every different approach like OOP, functional, relation DB, object DB, enterprise service bus + canonical documents,…

> Can you provide concrete examples of the things that you think are foundational in software?

Are you really expecting an answer here? I'll answer anyway.

• A big chunk of the CompSci curriculum is foundational.

• Making wrong states unrepresentable either via type systems or via code itself, using invariants, pre/post-conditions, etc. This applies to pretty much every tool or every language you can use.

• Error handling is a topic that goes beyond tools and languages, and even beyond whether you use try/catch, algebraic objects or values. It seeps into logging and observability too.

• Reasoning about time/space and tradeoffs of algorithms and structures, knowing what can and can't be computed, parsed, or recognized at all. Knowing why some problems don’t scale and others do.

• Good modeling of change, including ordering: immutability vs mutation, idempotency, retry logic, concurrency. How to make implicit timing explicit. Knowing which choices are cheap to undo and which are expensive, and design for those.

• Clear ownership of responsibilities and data between parts of the system via design of APIs, interfaces and contracts. This applies to OOP, FP, micro-services, modules and classes, and even to how one deals with third party-services beyond the basic.

• Computer basics (some of which goes back to 60s/70s or even back): processes, threads, green memory, scheduling, cache, instructions, memory hierarchy, threads, but races, deadlock, and ordering.

• Information theory (a lot goes to Claude Shannon, and back): compression, entropy, noise. And logic, sets, relations, proofs.

I never said there is a "simple rule" only foundational topics, but I'll say again: The biggest curse of software is people saying "no" to education and knowledge.

Re: You can't design software you don't work on

#103

Post by whstl »

emerent wrote: post #87
johnfn wrote: post #56

Earlier quoted context omitted.

I didn’t really get into it, but I think that most decisions which are not consistent are made with some feeling of “I will improve upon the existing state of this ugly codebase by introducing Good Decisions”. I’m sure even the authors of the Redux section of my code felt the same way. But code with two competing standards, only one good, is almost always worse than code with one bad standard. So breaking with consis…

You're getting a lot of pushback in the comments here and I don't understand why. This is exactly right. Stay consistent with the existing way or commit to changing it all (not necessary all at once) so it's consistent again, but better.

Nobody is pushing back about "commit to changing all".

Nobody is denying that "inconsistent" can be bad on its own.

But you can't say that "inconsistent but good" is bad by providing an example of how "inconsistent and bad" is bad.

Re: You can't design software you don't work on

#104

Post by whstl »

johnfn wrote: post #84
whstl wrote: post #81

Earlier quoted context omitted.

I don't know what to say. That’s a logic error. The claim was that "inconsistent but good" can exist, not that "inconsistent == good". Responding with one example where "inconsistent" turned out badly is a totally different claim and doesn't refute what GP says.

Who said that I only had one example? I just listed one so you'd have an idea of what I was talking about. I could give you like a hundred. This is a heuristic I've developed over a lot of time working in codebases with inconsistencies and repeatedly getting burned.

I'm not disagreeing with your example and conclusion, and I've seen many of those.

I actually agree that half-assing a problem is not the best solution.

It's just that they are not examples of "inconsistent but good". They are not even "good", just "inconsistent". You said yourself that they're worse overall.

Re: You can't design software you don't work on

#105

Post by roguecoder »

ilaksh wrote: post #25

This is also the type of thing that makes having separate software architects that aren't actually maintaining the software generally a nonsensical idea. There are too many decisions, technical details, and active changes to have someone come in and give direction from on high at intervals. Maybe at the beginning it could make sense sort of, but projects have to evolve and more often than not discover something impor…

The best "architects" serve as facilitators, rather than deciding themselves how software is built. They have to be reading the code, but they don't themselves have to be coding to be effective.

You don't need one until you've got 30-70 engineers, but a strong group of collaborative architects is the most important thing for keeping software development effective and efficient at the 30-1,000 engineer range.

Re: You can't design software you don't work on

#106

Post by DerArzt »

skydhash wrote: post #2

"Generic Software Design" as the author called it, is nice for setting the general direction of some implementation. This is why I like to read software engineering books. It's easier to solve a problem if you have some kind of framing to guide you. And it's easier to talk about the solution if everyone share the same terminology. But yes, the map is not the territory, and giving directions is not the same as walking…

Man I would kill for some direction from my "architects", even if it were a bit wrong. I'm at the point that I can't even get them to review my architectural diagrams demanded by my company to guide me on what's expected.

Re: You can't design software you don't work on

#107

Post by RaftPeople »

whstl wrote: post #102
RaftPeople wrote: post #99

Earlier quoted context omitted.

> Once again, that's only true at the surface level. Can you provide concrete examples of the things that you think are foundational in software? I'm thinking beyond "be organized so it's easier for someone to understand", which applies to just about everything we do (e.g. modularity, naming, etc.) For every different approach like OOP, functional, relation DB, object DB, enterprise service bus + canonical documents,…

> Can you provide concrete examples of the things that you think are foundational in software? Are you really expecting an answer here? I'll answer anyway. • A big chunk of the CompSci curriculum is foundational. • Making wrong states unrepresentable either via type systems or via code itself, using invariants, pre/post-conditions, etc. This applies to pretty much every tool or every language you can use. • Error han…

> Are you really expecting an answer here? I'll answer anyway.

Yes, and thanks for the examples, it's now clear what you were referring to. I agree that most of those are generally good fundamentals (e.g. wrong states, error handling, time+space), but some are already in complex territory like mutability. Even though we can see the problem, we have a massive amount of OOP systems with state all over the place. So the application of a principle like that is very far from settled or easy to have a set of rules to guide SE's.

> The software engineers' body of knowledge can change 52 times in a year

Nah, those changes are only in the surface, at the most shallow level.

I think the types of items you listed above are the shallow layer. The body of knowledge about how to implement software systems above that (the patterns and approaches) is enormous and growing. It's a large collection of approaches each with some strengths and weaknesses but no clear cut rule for application other than significant experience.

Re: You can't design software you don't work on

#108

Post by bitwize »

array_key_first wrote: post #100
bitwize wrote: post #70

Earlier quoted context omitted.

Well, that's just the problem, innit. In decades past, systems analysts performed a vital function, viewing the business and understanding its information flows as a whole and determining what information systems needed to be implemented or improved. Historically, in well-functioning information-systems departments, the programmer's job was confined to implementation only. Programming was just a translation step, goi…

IMO programs are 90% data or information, and modern software vastly underutilizes that concept. If you know what data you need, who needs it, and where it needs to go, you have most of your system designed. If you just raw dog it then stuff is all over the place and you need hacks on hacks on hacks to perform business functions, and then you have spaghetti code. And no, I don't think domain modeling solves it. It of…

This!

Per Fred Brooks: "Show me your flowcharts, but keep your tables hidden, and I shall continue to be mystified. Show me your tables, and I won't need to see your flowcharts; they'll be obvious."

It's telling that PRIDE incorporates the concept of Information Resource Management, or meticulous tracking and documentation of every piece of data used in a system, what it means, and how it relates to other data. The concept of a "data dictionary" comes from PRIDE.

Re: You can't design software you don't work on

#109

Post by lunias »

In my experience an "architect" is someone that used to write code (maybe 10-20 years ago - maybe only for a few years to begin with) but followed incentives away from the practice. Now they read blogs written by other architects about technologies that none of them have used. They champion the iterative process, but have 20 hard requirements up front that "make sure we can scale" (there are 5 users of this intranet app). They have 30 minutes free per day to produce any deliverables, all other time is spent in meetings. The deliverables produced are diagrams which have a few boxes and arrows pointing between them. Engineers are quick to ask, "Aren't those arrows backwards? We pull data from that service, right?". To which the architect replies without thought, "Ah, yeah, you're right. This is more of a work in progress, something to work off of." The next slide in their presentation is about database normalization and shows some data model that they hallucinated without looking at the data. The engineers chime in again, "Do we care more about the size of the data on disk or read times here?". The architect doesn't understand why you would challenge "best practices". You don't understand why the person presumably leading the initiative is unaware that computer science is fundamentally about trade offs.

It's not always like this, but the bigger the company, the more statistically probable it is.

Re: You can't design software you don't work on

#110

Post by whstl »

RaftPeople wrote: post #107
whstl wrote: post #102

Earlier quoted context omitted.

> Can you provide concrete examples of the things that you think are foundational in software? Are you really expecting an answer here? I'll answer anyway. • A big chunk of the CompSci curriculum is foundational. • Making wrong states unrepresentable either via type systems or via code itself, using invariants, pre/post-conditions, etc. This applies to pretty much every tool or every language you can use. • Error han…

> Are you really expecting an answer here? I'll answer anyway. Yes, and thanks for the examples, it's now clear what you were referring to. I agree that most of those are generally good fundamentals (e.g. wrong states, error handling, time+space), but some are already in complex territory like mutability. Even though we can see the problem, we have a massive amount of OOP systems with state all over the place. So the…

> I think the types of items you listed above are the shallow layer

They are not, by definition. You provided proof for it yourself: you mention the "body of knowledge [...] above that", so they really aren't the topmost layer.

> is enormous and growing

That's why you learn the fundamentals. So you can understand the refinements and applications of them at first glance.

Post reply on HN