Live data from Hacker News

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

seangoedecke.com

111–119 of 119 posts

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

#111
post #110

Earlier quoted context omitted.

> 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.

> 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

I said "shallow", not "topmost".

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

Can you explain when (if ever) a person should use an OOP approach and when (if ever) he/she should use a functional approach to implement a system?

I don't think those fundamentals listed above help answer questions like that and those questions are exactly what the industry has not really figured out yet. We can see both pros and cons to all of the different approaches but we don't have a body of knowledge that can point to concrete evidence that one approach is preferred over the many other approaches.

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

#112
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…

Nobody wants to wait for those cycles to happen in the sorts of businesses that feature most prominently on HN. That flow works much better for "take existing business, with well defined flows, computerize it" than "people would probably get utility out of doing something like X,Y,Z, let's test some crap out." Now, later-stage in those companies, yes, part of the reason for the chaos is because nobody knows or cares…

> Nobody wants to wait for those cycles to happen in the sorts of businesses that feature most prominently on HN.

Bryce's Law: "We don't have enough time to do things right. Translation: We have plenty of time to do things wrong." Which was definitely true for YC startups, FAANGs, and the like in the ZIRP era, not so much now.

Systems development is a science, not an art. You can repeatably produce good systems by applying a proven, tested methodology. That methodology has existed since 1971 and it's called PRIDE.

> That flow works much better for "take existing business, with well defined flows, computerize it" than "people would probably get utility out of doing something like X,Y,Z, let's test some crap out."

The flows are the system. Systems development is no more concerned with computers or software than surgery is with scalpels. They are tools used to do a job. And PRIDE is suited to developing new systems as well as upgrading existing ones. The "let's test some crap out" method is exactly what PRIDE was developed to replace! As Milt Bryce put it: "do a superficial feasibility study, do some quick and dirty systems design, spend a lot of time in programming, install prematurely so you can irritate the users sooner, and then keep working on it till you get something accomplished." (https://www.youtube.com/watch?app=desktop&v=SoidPevZ7zs&t=47...) He also proved that PRIDE is more cost-effective!

The thing is, all Milt Bryce really did was apply some common sense and proven principles from the manufacturing world to systems development. The world settled upon mass production using interchangeable parts for a reason: it produces higher-quality goods cheaper. You would not fly in a plane with jet engines built in an ad-hoc fashion the way today's software is built. "We've got a wind tunnel, let's test some crap out and see what works, then once we have a functioning prototype, mount it on a plane that will fly hundreds of passengers." Why would a company trust an information system built in this way? It makes no sense. Jet engines are specced, designed, and built according to a rigorous repeatable procedure and so should our systems be. (https://www.modernanalyst.com/Resources/Articles/tabid/115/I...)

> Which is arguably happening in some sectors now, though the AI wave is making other sectors even more frothy than ever at the same time in the "just try shit fast!" direction.

I think the AI wave will make PRIDE more relevant, not less. Programmers who do not upskill into more of a systems analyst direction will find themselves out of a job. Remember, if you're building your systems correctly, programming is a mere translation step. It transforms human-readable specifications and requirements into instructions that can be executed by the computer. With LLMs, business managers and analysts will soon be able to express the inputs and outputs of a system or subsystem directly, in business language, and automatically get executable code! Who will need programmers then? Perhaps a very few, brilliant programmers will be necessary to develop new code that's outside the LLMs' purview, but most business systems can be assembled using common, standard tools and techniques.

Bryce's Law: "There are very few true artists in computer programming, most are just house painters."

The problem is, and always has been, that all of systems development has been gatekept by programmers for the past few decades. AI may be the thing that finally clears that logjam.

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

#113
post #63

> I don’t know if structural engineering works like this, but I do know that software engineering doesn’t. Structural Engineering (generally construction engineering) does work like that. Following the analogy, the engineers draw; they don't lay bricks. But, all the best engineers have probably been site supervisors at some point and have watched brick being layed, and spoken to the layers of bricks, etc. Constructio…

My father mentored some engineering college students about 15 years ago. He came away from the experience a bit disappointed: they knew how to model a part, but not how to machine one. When he came up in the world of slide-rule-and-drafting-pencil mechanical engineering, every engineer knew, in principle at least, how to machine a part; such knowledge was necessary for good designs because a design was instructions t…

In CAD you can make an arbitrarily sized hole, in the real world you can only drill holes if you have the corresponding drill bit.

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

#114
post #110

Earlier quoted context omitted.

> 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.

> 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 I said "shallow", not "topmost". > That's why you learn the fundamentals. So you can understand the refinements and applications of them at first glance. Can you explain when (if ever) a person should use an OOP approach and when (if ever) he/she should use a…

I'm really sorry, but if you think those topics above are "shallow", I don't think we have much to talk about and should probably agree to disagree.

> Can you explain when (if ever) a person should use an OOP approach and when (if ever) he/she should use a functional approach to implement a system?

I can, and have done several times, actually, for different systems.

> I don't think those fundamentals listed above help me

The list I gave was not exhaustive. You asked yourself for "concrete examples" and I gave examples.

The reason I can't answer hard questions in a simple message is exactly because those foundations are not "shallow" at all.

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

#115
post #114

Earlier quoted context omitted.

> 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 I said "shallow", not "topmost". > That's why you learn the fundamentals. So you can understand the refinements and applications of them at first glance. Can you explain when (if ever) a person should use an OOP approach and when (if ever) he/she should use a…

I'm really sorry, but if you think those topics above are "shallow", I don't think we have much to talk about and should probably agree to disagree. > Can you explain when (if ever) a person should use an OOP approach and when (if ever) he/she should use a functional approach to implement a system? I can, and have done several times, actually, for different systems. > I don't think those fundamentals listed above hel…

> I can, and have done several times, actually, for different systems.

The reason I asked that question isn't to be argumentative, it's because, IMO, the answer to those types of questions are exactly what does not exist in the software engineering world.

And talking through the details of our different opinions is how we can understand where each one is coming from and possibly, maybe, incorporate some new information or new way of looking at things into our mental models of the world.

So, if you do think you have an answer, I am truly interested in when you think OOP is appropriate and when functional is better suited (or neither).

If someone asked me that question, I would say "If we're in fantasy land and it's the first system ever built and there are no variables related to existing systems and supportability and resource knowledge, etc., then I really can't answer the question. I've never built a system that was significantly functional, I've only built procedural, OOP and mixtures of those two with sprinklings of functional. I know there are significant pros to functional, but without actually building a complete system at least once, I can't really compare"

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

#116
post #70

Earlier quoted context omitted.

I don't think I've ever worked on a project that had "system analysts". You might as well say "this is what happens when you don't allow sorcerers to peer into the future". Best I've ever had are product managers who maybe have a vague idea of what the customer wants.

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…

In the construction world, it's basically the separation between architects and builders.

Sure you can definitely build things and figure out things along the way. But for any sufficiently complex project, it's unlikely to yield good results.

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

#117
post #114

Earlier quoted context omitted.

I'm really sorry, but if you think those topics above are "shallow", I don't think we have much to talk about and should probably agree to disagree. > Can you explain when (if ever) a person should use an OOP approach and when (if ever) he/she should use a functional approach to implement a system? I can, and have done several times, actually, for different systems. > I don't think those fundamentals listed above hel…

> I can, and have done several times, actually, for different systems. The reason I asked that question isn't to be argumentative, it's because, IMO, the answer to those types of questions are exactly what does not exist in the software engineering world. And talking through the details of our different opinions is how we can understand where each one is coming from and possibly, maybe, incorporate some new informati…

You asked whether one should use OOP or FP to implement a system.

I can answer that, and did in the past, as I have done projects in both OOP and FP. But before I answer, I ask follow-up question about the system itself, and I will be giving lots of "it depends" and conditions.

There is no quick and dirty rule that will apply to any situation, and it's definitely not something I can teach in a message board.

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

#118

> You can't design software you don't work on In 30 years in software dev, I am yet to see any significant, detailed and consistent effort to be extended into design and architecture. Most architects do not design, do not architect. Senior devs design and architect and then take their design to the architects for *feedback and approvals*. These senior devs make designs for features and only account for code and syste…

There are those comedians who talk with people in IT (mostly various types of roasts). People laugh, but it is incredibly sad that for example someone from the Android team does not use an android phone for a daily driver.

Microsoft had a lot of sins, but at least they asked the coders to eat own dogfood.

Also the "2 year coding wizards" that you described usually dont live up to see the results (or rather: disasters) of their decisions + they dont have to maintain their own code.

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

#119
post #118

> You can't design software you don't work on In 30 years in software dev, I am yet to see any significant, detailed and consistent effort to be extended into design and architecture. Most architects do not design, do not architect. Senior devs design and architect and then take their design to the architects for *feedback and approvals*. These senior devs make designs for features and only account for code and syste…

There are those comedians who talk with people in IT (mostly various types of roasts). People laugh, but it is incredibly sad that for example someone from the Android team does not use an android phone for a daily driver. Microsoft had a lot of sins, but at least they asked the coders to eat own dogfood. Also the "2 year coding wizards" that you described usually dont live up to see the results (or rather: disasters…

>Eat your own dog food

The end.

Post reply on HN