News for hackers. Stuff that matters.
Re:Software Architecture Guide by chrisseaton on Saturday August 24, 2019 @09:00AM (#20786893)
For some of these speakers, I’ve literally never seen any evidence that they’ve written a single line of code. Why should we listen to Fowler? What large successful projects has he created using his ideas are there that I can look at? Where’s the data behind his slides? It’s all just talk talk talk.

I’d listen to someone like Chris Lattner talk about how to design and write software because I can see whatever approach he uses must work well. I should listen to these full-time speakers because... I don’t really know and perhaps we should start challenging their talks by asking for the data behind them.

Re:Software Architecture Guide by rhizome31 on Saturday August 24, 2019 @09:56AM (#20787148)
I don't think Fowler pretends to be much of an innovator. The way I see it his work consists in collecting and documenting existing ideas from the industry. You'll find many instances of patterns listed in PoEAA in open-source frameworks. His "refactorings" are also pretty simple ideas that people generally come up with on their own after a bit of work experience. It's just nice to have a nicely formatted book where they're given a name and they're illustrated by diagrams and examples, especially to help junior developers. You'll also notice that for each pattern or refactoring, Fowler generally tries to show its caveats. So it's not like he tries to sell his ideas at all costs. Note that here I'm talking specifically about Fowler, whose work I have found helpful with my real world projects.
Re:Software Architecture Guide by scarface74 on Saturday August 24, 2019 @09:24AM (#20786985)
Chris Lattner knows how to write system software and compilers which are completely separate beasts from the typical bespoke enterprise or software as a service apps that most developers write every day.
Re:Software Architecture Guide by vfc1 on Saturday August 24, 2019 @10:41AM (#20787370)
Exactly, many times these famous authors advocate for practices that make sense for building compilers and frameworks or libraries, but that make little sense for building applications.

Building applications is very different, because an application is the very end of the software tree dependency. Some practices make sense for both types of software, but many others don't and some of these authors don't seem to be able to make the difference.

Re:Software Architecture Guide by scarface74 on Saturday August 24, 2019 @10:48AM (#20787401)
And sometimes it makes sense to take shortcuts that don’t make sense from a long term maintenance standpoint just to survive long enough to get product market fit. Get funding and survive.

Twitter is a perfect example of this. Everyone agrees that Twitter made some bad architectural decisions that caused the frequent appearance of the “fail whale”. But eventually, they got enough funding via combination of the VC funding and later the public market to rearchitect their system.

Re:Software Architecture Guide by legulere on Saturday August 24, 2019 @10:47AM (#20787396)
System Software isn’t all that different from enterprise software. The business part is simply of technical nature. The biggest difference usually is that the software developers don’t have a deep understanding of the business rules.
Re:Software Architecture Guide by scarface74 on Saturday August 24, 2019 @10:56AM (#20787442)
I’ve had to maintain a bespoke compiler/IDE/VM for Windows Mobile/CE before and have spent two decades writing business software and architecting around the entire stack from networks, to databases, to web servers, load balancers, monitoring tools etc. I’ve also written SOWs, Done project plans, led teams (hated every minute of it). I’ve seen both sides.

The types of optimizations and thought processes around enterprise software is completely different than the optimizations around compilers.

The “entire stack” with enterprise software is much different than the “entire stack” with the compiler. I haven’t had a need to look at the assembly created from my compiler as a business software developer since around 2002.

For context, my first hobby programming was in the 80s optimizing 65C02 programs by using zero page memory access to eke a little more speed out of the 1Mhz processor and trying to use branch statements instead of JMP statements because they were faster.

Re:Software Architecture Guide by legulere on Saturday August 24, 2019 @11:42AM (#20787769)
Of course you’re not looking at generated assembly anymore because that is the business value of a compiler. The biggest difference now is that you’re probably not as big an expert in the enterprise topic as you were about generating assembly.
Re:Software Architecture Guide by scarface74 on Saturday August 24, 2019 @11:50AM (#20787818)
These days - no. I’m nowhere near the business expert in the healthcare industry where I now work as I was in the ins and outs of assembly. That’s not my role. I’m a software developer by title, but I would consider myself an “expert” in both the software architecture and the AWS infrastructure of our (smallish) company.

When I was working for the company where I did have to maintain the compiler/IDE/VM after they forced their founder out. I also had to know the complete business needs of the client that kept us afloat because as they laid off people, I had to interact with the customer and write the SOWs. I saw both sides. The skillset I needed to implement the business side was completely different than the skillset I had to have to maintain the compiler stack.

Luckily I was mature enough (and an MBA dropout) to understand the business end and enough of a geek to understand low level computer concepts and could read assembly.

Re:Software Architecture Guide by EdwardDiego on Saturday August 24, 2019 @11:02AM (#20787486)
https://github.com/unclebob might be a good place for you to start. Fitnesse is probably the biggest one on there.

You can't really hold the fact that most of his working life has been for closed source orgs against him.