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

FizzBuzz Enterprise Edition

fizzbuzz.enterprises

Post reply on HN
Print view View original

51–60 of 72 posts

Re: FizzBuzz Enterprise Edition

#51

Post by kartan »

royalghost wrote: post #46

Looking at the problem statement, this should be built in a Reactive style of programming and more event based. What if we need to scale this to infinite numbers for millions of clients ? Event based programming in technology like stack is more appropriate for this kind of problem domain...

> What if we need to scale this to infinite numbers for millions of clients?

I worked for a company where an internal tool for, at the moment, a dozen users was designed to be more scalable than the actual product. The product was used, without major problems, by hundreds of millions of users. So we had a team of 14 people to build something that previously was done by one guy in an already maintainable way.

The server was also divided into several components to mimic a micro-service architecture. Even that no one else was using any of the services and it made deployment cumbersome.

To cut a long story short, the company has a-lot-of-money to throw at problems. So waste is not a big deal. I moved on, as it was boring to work that way.

Many backend developers feel proud of their complex architecture. Simplicity is seen as "not being professional".

For the client side of that app, there was just one guy. He was also acting as scrum master because he had spare time.

Re: FizzBuzz Enterprise Edition

#52

Post by LoSboccacc »

Asooka wrote: post #21

Where/how does one learn to structure programs like this? Obviously I won't write fizzbuzz like this, but the point is it won't occur to me to structure a fizzbuzz solution like this. And if I can't produce such a structure for the dead simple case, then I can't trust myself to be able to architect an actual complex system where one does need to apply all these abstractions. Are these skills only attainable from year…

people loves enterprise architecture jokes but all starts with some questions: what if I need to use the client datasource for the input numbers? what if a client ask to send the output to a network endpoint? to a printer?

so you start decoupling things. this here is played for fun, but if you need to build something that lasts 10 years across a multitude of clients instead of just as an one off project those question starts to be legitimate.

Re: FizzBuzz Enterprise Edition

#53

Post by auspex »

Asooka wrote: post #21

Where/how does one learn to structure programs like this? Obviously I won't write fizzbuzz like this, but the point is it won't occur to me to structure a fizzbuzz solution like this. And if I can't produce such a structure for the dead simple case, then I can't trust myself to be able to architect an actual complex system where one does need to apply all these abstractions. Are these skills only attainable from year…

You should first learn about design patterns and then read Patterns of Enterprise Architecture by Martin Fowler. The book basically outlines how to think like this.

Re: FizzBuzz Enterprise Edition

#55

Post by PascLeRasc »

_pmf_ wrote: post #9

The documentation is not Enterprise Ready™; it still contains a description of what the product actually does in an accessible location. For proper compliance, this description should be in a PDF whitepaper that will only be mailed to you after providing your e-mail address and phone number.

Real Enterprises would print out the PDF and scan it back in and then delete the original.

Re: FizzBuzz Enterprise Edition

#56

Post by charleslmunger »

jcelerier wrote: post #50
frfl wrote: post #32

On a more serious note. What is the alternative to the OOP IOC SOLID multiple layers of abstraction way of doing things? Is this really the go to architecture for enterpire - or more appropriately, large projects? Why is it the go to architecture -- what are the alterntives? Suppose we're discussing a project in a non-typical OOP language (not Java/C#/C++), what is the architure of choice there? Asking this as a juni…

> Is this really the go to architecture for enterpire - or more appropriately, large projects? You have to understand that the context in which this kind of architecture is needed is high-turnovers environments. Basically, in the 90's, managers at big corps - IBM, ATOS, etc... asked the question : "how can we fire a whole team, hire a whole another team and put them in front of the fired team's code and have them be…

I'd like to reframe this a bit:

> "how can we fire a whole team, hire a whole another team and put them in front of the fired team's code and have them be productive in a few days ?".

What's really happening here is "how can we fire a whole team, hire a whole another team and have the new team be as productive as the old team was?"

You might think documentation, clean architecture, avoid feature creep etc... but what's really happening is that the old team is not productive by any absolute measurement.

Re: FizzBuzz Enterprise Edition

#57

Post by acobster »

kartan wrote: post #51
royalghost wrote: post #46

Looking at the problem statement, this should be built in a Reactive style of programming and more event based. What if we need to scale this to infinite numbers for millions of clients ? Event based programming in technology like stack is more appropriate for this kind of problem domain...

> What if we need to scale this to infinite numbers for millions of clients? I worked for a company where an internal tool for, at the moment, a dozen users was designed to be more scalable than the actual product. The product was used, without major problems, by hundreds of millions of users. So we had a team of 14 people to build something that previously was done by one guy in an already maintainable way. The serv…

I've faced a similar situation, where a team I came to work on mid-project had designed a microservice architecture where a WordPress front-end talked to some "middleware" (a total misnomer since it was actually a REST API) which in turn talked to a bunch of other intermediate services which in turn talked to the CRM, an accounting system, and other third-party systems. Most of the "middleware endpoints" simply forwarded the calls to other services. Any feature that required a new endpoint usually meant deploying changes to three different systems.
Post reply on HN