Fighting Complexity in Software Development • Hacker News Board

Re: Fighting Complexity in Software Development

#81

Post by morgancmartin » Fri, Jul 05, 2019, 1:29 PM UTC

pytester wrote: post #68

alkonaut wrote: post #66

Earlier quoted context omitted.

I agree - in a prototyping phase it may be beneficial to be able to throw something together. The problem is that what you throw together is invariably the base for the real thing. The motto of "design one to throw away" is great, but I haven't seen it applied as much as it should. Using a "stiff" set of tools might slow down the first stages of prototyping, but it also makes the prototype easier to modify as require…

>The problem is that what you throw together is invariably the base for the real thing. This isn't invariable at all. More often what you throw together gets thrown away. I'd estimate this happens to more (working) code I've written over my career than not. The hardest thing to get right is often getting the contours of a tool right and ascertaining what it should do - not making it work right after it has proven its…

> If F# or rust or haskell really was quicker and more effective in a prototyping environment as well as when writing production hardened code, programmers would likely eventually converge on only using them. That isn't what is happening.

This does not seem to me to be a safe assumption to make. The market is irrational. There is no reason to believe popularity has any significant correlation to the effectiveness of a tool.

Re: Fighting Complexity in Software Development

#82

Post by walshemj » Fri, Jul 05, 2019, 1:39 PM UTC

Chyzwar wrote: post #8

In mature OOP you have ways to write nice models and have good validations. https://guides.rubyonrails.org/active_record_validations.htm... I will argue that the complexity of software development is not because of OOP vs Functional. Tooling, documentation, quality of libraries and people are what matter most. Ruby was a massive success is largely attributed to above. We are humans, we can understand and deal with a…

I think the argument is that for a lot of cases OOP isn't the right paradigm

Re: Fighting Complexity in Software Development

#83

Post by wayoutthere » Fri, Jul 05, 2019, 1:46 PM UTC

jaequery wrote: post #46

jumpinalake wrote: post #23

Earlier quoted context omitted.

Couldn’t agree more. I was part of a $30 million Rails project that got unmanageable and burned after 2-3 years. Golang is so much more forgiving to human error.

30M. Well there’s your problem. I can just imagine the premature optimizations and the bloated abstraction that went in the planning phases.

Yeah, welcome to enterprise development (regardless of programming language). Every VP fancies themselves as the next Steve Jobs and like to be uncompromising about delivering their vision. Which ironically ends up as design by committee when you have that many assholes in a room unwilling to back down but also needing to save face.

And to be fair, most of the premature optimization and bloated abstractions are just your architects sitting around bored for 6 months while the project sponsors argue over reporting minutiae (but won’t approve the designs until their pet features are pulled in on the roadmap). They know the entire feature list is going to get changed at the last minute as the political winds shift, so they’re designing an overbuilt architecture to CYA for whatever random bullshit someone will pull a week before a deadline.

Re: Fighting Complexity in Software Development

#84

Post by vharuck » Fri, Jul 05, 2019, 1:48 PM UTC

losteric wrote: post #37

jes5199 wrote: post #17

Earlier quoted context omitted.

but have you ever had to maintain a ruby project after the first year? The cost just goes up and up, and I think it’s because the language is so hostile to static analysis.

Yes. I've been working on an corporate internal RoR tool that launched in 2010. Various engineers over the years continued releasing new features and updating language/framework development... when I earlier this year, development/maintenance cost was no higher than any other software of that nature and age. Cost only goes up and up when engineers go overboard with "clever" Ruby magic... which is human error, don't b…

>Cost only goes up and up when engineers go overboard with "clever" Ruby magic... which is human error, don't blame the tool.

I've only used a few languages in production for my non-developer job, but I've noticed very different frequencies of "clever" code between them.

R: This is my primary language. I love it, but it almost encourages clever coding. There are 10 ways to do any task without even touching third-party packages.

Python: My secondary language at work. Clever coding is definitely possible in Python, but the language's syntax makes it easy to spot. Detection isn't as good as prevention but it's better than nothing.

(I also grudgingly use SAS, but won't waste my time looking for ways it encourages clear coding.)

Re: Fighting Complexity in Software Development

#85

Post by marcc » Fri, Jul 05, 2019, 2:04 PM UTC

kazinator wrote: post #14

The main source of complexity is requirements. Gatekeeping against the influx of requirements will keep complexity down. Then there is unnecessary complexity from doing incomplete refactorings and rewrites. If some code cannot handle the addition of a new requirement, it should be replaced. Otherwise you add complexity that roughly takes the logical (if not actual) form if (these cases) { new code } else { old code }…

It's easy for us to blame "requirements" as the main source of complexity. This isn't accurate. Software exists to serve the needs of the business. Depending on the maturity and stage of the business or the software itself, it's possible that there's a changing set of requirements. As developers, it's out job to figure out how to deliver, not to say "no" to new enhancements and requirements.

The main source of complexity is how we write software, not that the software has requirements.

Re: Fighting Complexity in Software Development

#86

Post by marcc » Fri, Jul 05, 2019, 2:09 PM UTC

hardwaresofton wrote: post #70

I really support this kind of writing, I don't think this kind of stuff is written about enough, and it's exactly what everyone learns the hard way working on software projects. Skill wise, knowing the kinds of reasoning/techniques that articles like these discuss is the difference between "junior" and "senior" developers (though I very much dislike those terms). One thing I want to point out -- if at all possible do…

Agreed. I dislike the terms "sr" and "jr" developer, but I think we too often call someone a senior because they know a lot of technology or they've been around for a while.

I've been thinking a lot about these terms and have been defining these roles internally as:

junior: can build relatively simple solutions, still gaining experience.

mid-level: can build complex systems, but the solution is going to be complicated.

senior: builds simple solutions to solve complicated problems.

I mentor internal devs to help shift their focus from learning more complicated technologies toward learning how to produce much cleaner and simpler solutions. This is the career path that I think helps them the most and also helps our company scale.

Re: Fighting Complexity in Software Development

#87

Post by ChicagoDave » Fri, Jul 05, 2019, 2:12 PM UTC

Reducing complexity starts with abstracting bound contexts, understanding relationships between them, identifying ubiquitous languages, understanding the autonomous bubble pattern, and then worrying about code.

I’d add DAL should be shelved for a repository pattern and business layer shelved for root aggregates and value objects.

It’s all in Eric Evans’ Domain Driven Design book that still carries enormous weight.

Re: Fighting Complexity in Software Development

#88

Post by pjmlp » Fri, Jul 05, 2019, 2:13 PM UTC

Chyzwar wrote: post #8

In mature OOP you have ways to write nice models and have good validations. https://guides.rubyonrails.org/active_record_validations.htm... I will argue that the complexity of software development is not because of OOP vs Functional. Tooling, documentation, quality of libraries and people are what matter most. Ruby was a massive success is largely attributed to above. We are humans, we can understand and deal with a…

The irony is that Smalltalk already offered many FP patterns.

In the end multi-paradim languages will win.

What many FP advocates fail to acknowledge is that all FP languages that got some kind of mainstream adoption, might be FP first, but they are actually multi-paradigm.

Re: Fighting Complexity in Software Development

#89

Post by pjmlp » Fri, Jul 05, 2019, 2:15 PM UTC

alkonaut wrote: post #58

cottsak wrote: post #28

Earlier quoted context omitted.

Agree. You can write terse, maintainable, well encapsulated, testable and readable code in most any language. The problem is about the humans not the language they select. But yes, complexity is also a major problem.

What I have learned is that what makes a language (or platform, or tool) "good" isn't how easy it is to write good code, but how hard it is to write bad code. Does a beginner following the path of least resistence, on a tight schedule, end up with maintainable code or not? I'd argue that this is the weakness with (the traditional) OO languages. An experienced developer with plenty of time can write good software with…

On the other hand, very few languages are capable to rival C++, Java, C# in terms of tooling and available libraries.

Re: Fighting Complexity in Software Development

#90

Post by couchand » Fri, Jul 05, 2019, 2:15 PM UTC

jorams wrote: post #73

hardwaresofton wrote: post #70

I really support this kind of writing, I don't think this kind of stuff is written about enough, and it's exactly what everyone learns the hard way working on software projects. Skill wise, knowing the kinds of reasoning/techniques that articles like these discuss is the difference between "junior" and "senior" developers (though I very much dislike those terms). One thing I want to point out -- if at all possible do…

> The problem here is that decimal is the wrong type for storing money Note that the code here is .NET, where decimal is a type explicitly for use in financial calculations[0]. It is still floating point, which means you still need to really watch what you are doing, but it's very high precision. In general though, if your application allows for it, you should store money using integers representing cents (or the rel…

> It is still floating point, which means you still need to really watch what you are doing, but it's very high precision.

The key difference between a decimal type (in any language) (regardless whether it's fixed-point or floating-point) is that it's not BINARY floating point. Yes, you need to watch what you are doing (shouldn't you always?)... but you can limit analysis to the appropriate precision, without worrying about binary conversion artifacts like 0.3 isn't 0.3.

> In general though, if your application allows for it, you should store money using integers representing cents.

What you're describing is a poor man's fixed point. Much better to just use a fixed point decimal type so you don't need to remember to apply the scale factor everywhere.

In any case, you can't get around the need to determine a ceiling in your necessary precision.