1. 3

    I have found most self submitted content to be of interest. That being said, submitting too often would be a problem. Some limit to the number of self submitted links?

    1. 4

      A timely article given my need to find a new browser after an automatic update ruined my browser a couple of days ago.

      Firefox for Android was updated from a product I was extremely happy with, to a different one I am extremely unhappy with. All without being given a choice or notice.

      1. 31

        This is what has kept me busy the past 18 months. Ask me anything :-)

        1. 12

          I’ve been using the preview for a while, and I like it a lot. Thanks to you and everyone at Mozilla.

          Moving the address / tool bar to the bottom of the screen is, imho, a very clever decision that made my huge phablet phone a bit less painful to use.

          1. 7

            After using Firefox on Android for as long as I can remember, I have changed browsers.

            Every time I start the new version my screen flashes. I perceive no performance improvements or “experience” benefits. On the contrary my favorite extensions no longer work.

            My question is, why should I use/return to this new version?

            1. 6

              Same here, even on my latest Google Pixel, the Firefox performance was awful, the browser experience was not good. But now I’m very happy with the latest version, I can see real good improvements, the browser experience is great and it’s not resource hungry as the oldest version. I would like to congratulate the Mozilla team for the great job!

            2. 7

              I… hated it. Especially I feel like there wasn’t enough testing with the bar configured on top. I wrote a rant with the issues I have, which will probably read as too angry for a lobste.rs comment but allowed me to vent my frustration.

              For now I set the bar on the bottom, which I don’t really like but solves 2 issues (buggy sites, and the new tab button being too far).

              Still thank you for your work. I couldn’t get anything done without firefox in my pocket.

              1. 9

                Another issue not listed: I will sometimes come back to firefox to find an old tab is now completely blank. Reloading will not help: I have to close the tab and open it again. I’ve had this happen with both a lobsters tab and a completely unrelated site… I will have to try and find a reproducible way to trigger it, could be hard.

                1. 3

                  I’ve had that issue on desktop firefox. If the site is bookmarked, I click it (helpful especially if it was a container tab)

              2. 6

                Lots of users hate the new tab drawer (vs. the original tab page in earlier Firefox Preview builds). I don’t think it matters whether it’s a drawer or a full screen page, but the fact that scrolling to the top of the list continues into closing the drawer is extremely annoying. I do not ever want to close the drawer by moving my finger down on the list of tabs!! Please make an option to only have the header draggable for closing.

                1. 5

                  Any plans for completing the bookmark feature?

                  1. 4

                    Will it it be made available on F-Droid? Soon? Ever?

                    How does this release relate to these:

                    Getting Firefox via F-Droid has always confused me, so I’ve stayed away, but I’m always on the lookout for a good browser for Android.

                    1. 2

                      No idea about Klar, but Fennec is similar to IceCat: Firefox with the proprietary blobs removed. I think F-Droid doesn’t like vanilla Firefox for the reason that it contains blobs.

                      1. 2

                        My recollection is that F-Droid’s Fennec build is just Firefox with the trademarks removed, not proprietary blobs. The new Firefox for Android, Fenix, doesn’t get packaged because its standard build system involves downloading pre-compiled copies of other Mozilla components, like the GeckoView widget, rather than building absolutely everything from source. F-Droid does allow apps that download pre-compiled copies of things, but only if they’re obtained from a blessed list of Maven repositories, and Mozilla’s CI system is not on the list.

                        Also, there may be something about requiring the Play Store to support notifications, but I don’t think it’s the only or even the biggest blocker.

                        1. 3

                          Ah, sounds like you know a more about this than me - I stand corrected. Thanks for the information!

                    2. 4

                      why block about:config? why no arbitrary extensions on your own risk? I would love a split screen or dual window feature.

                      1. 3

                        One thing I would absolutely love is socks5 proxy support. Any plans for that? Also, I use ^L and ^K a freakton in the desktop browser. I’d love to see support for that when using Firefox for Android on ChromeOS.

                        1. 3

                          How can I downgrade without losing my settings and open tabs?

                          1. 2

                            Great work! It sounds like there’s been a lot of work going on under the hood for this release, and there’s mentioning of it now being easier to make new features in the product. Are there any blog posts - or could you talk a bit about what changes that has been made which now unlocks this extra velocity?

                            1. 2

                              I use Android with a keyboard.

                              Do you know of any keyboard-driven browsing solutions like Vimium on Android at this time?

                              1. 2

                                Any way to display your bookmarks on startup or something like this ? I’m used to switching through my bookmarks, now I’ve got to add them all to this “collection”(? german word is “Sammlung”) and that is collapsed every time I create a new tab. “Add to start screen” doesn’t do anything.

                                1. 1

                                  Finally found the option to add it as part of the start screen. The new Bookmarks view is hard for me to grasp, like everything looks the same.

                                2. 1

                                  This is the version that finally made me rate Firefox in Play store: to 1 star! Why did you (plural) make it this bad?

                                  Things that broke:

                                  • setting DuckDuckGo up a default search engine was simple in the past as I remember. It was auto-discovered, I think, I installed Firefox quite a time ago. Now I had to manually edit a search string.
                                  • The text selection menu is totally useless. I used to have “copy to clipboard” and “search <default search provider” there. Now I have to push “…” and scroll a tiny list with useless items populated by some incomprehensible logic, containing apps installed on my phone eg. a “pdf reader”, “encrypt”, “private search”, “Firefox search”, “new task”. Lot of useless crap instead of a single simple workflow. The “Firefox Search” option is the functional equivalent of the old operation, but it is at the bottom of the list, so it is a pain to use.
                                  • icons in the start page are smaller, and the workflows on their manipulation are not intuitive.
                                  • tab selection is terrible. The tabs opened in the background are at the top of the tab stack, but the current tab is at the top of the screen, and there are no visual cues that there may be other tabs above, you need to scroll both ways to find what you are looking for…

                                  The whole UX suggest that the developers don’t use Firefox for daily browsing. The feature are there, the UX is terrible, and is a regression in every possible aspect.

                                  The single good thing is the address bar in the bottom. I’d prefer to downgrade to an older version actually, as the previously advertised speed benefits are not noticable.

                                  The PR page states:

                                  User experience is key, in product and product development

                                  Maybe I’m not the target audience?

                                  I know this is not your (singular) fault, more likely a project management issue, but I think the direction is not the right one.

                                  1. 1

                                    Hi Stefan, please take a look at brave on mobile. I was eagerly waiting for Brave UX in firefox and chrome. Fantastic news that firefox.

                                    One suggestion - After clicking on tab number at right bottom corner to open new tab, is it possible to slide to normal window to incognito windows by sliding on screen rather than click on each icon. This will be especially helpful for mobile or tablet with big screens.

                                    Again, big thanks making such huge change possible.

                                    1. 1

                                      Just got the update. Really liking the bar on the bottom.

                                    1. 2

                                      Thanks and happy birthday!

                                      1. 2

                                        I find the author looking in the wrong place. There are a lot of different types of software, but three types form a large majority: control (and data acquisition) systems; simulations; systems featuring the recording of transactions for commercial or legal reasons.

                                        In common are that they are all about modeling some system, real or imagined, in computer code. These include those systems that manage your money, taxes, insurances, health, utilities, environment, purchasing, supply, services, education and reservations. They include the systems that operate your elevator, reticulation system, production line, or automated warehouse.

                                        What’s wrong with software is that programmers have not been able to adopt and teach a predictable and repeatable way to model into code. As Hertz learned recently with its failed systems by Accenture, the undertaking of high cost complex systems is a dangerous and uncertain undertaking. What progress have we made?

                                        Capital in this context is about the *ownership” of resources that might include a decision to automate some process that could be performed instead given enough human resources and means of communication. Capital and the production of speculative undertakings featuring software are not where software “went wrong”. Instead software might be a mere detail in the relationship between capital and a speculative endeavor of any kind?

                                        1. 1

                                          Would you please define what you mean by ‘model’?

                                          1. 1

                                            There are many definitions of model. The closest one I can think of that matches your usage is:

                                            ‘A schematic description or representation of something, especially a system or phenomenon, that accounts for its properties and is used to study its characteristics.’ (Source: Wordnik)

                                            While this definition is consistent with portions of the three types of software you describe: (‘control (and data acquisition) systems; simulations; systems featuring the recording of transactions for commercial or legal reasons.’), it does cover all aspects of them.

                                            For parts of software systems that interact with humans, there is more than just modeling in the above sense. Of course, there are decisions about what to model. Even more broadly, there is design about the human-computer-interaction: e.g. what is shown to the human (and when), what mechanisms exist for human input.

                                            I would suggest that most/all software systems (ultimately) are to some degree coupled with humans, and thus have designs (implicit or explicit) about their context, which may touch on any or all aspects of human existence.

                                            1. 1

                                              You make a good point that modeling is a hard problem in software.

                                              However, when you write ‘What’s wrong with software is [one thing]’, you commit the ‘fallacy of the single cause.’

                                              The fallacy of the single cause, also known as complex cause, causal oversimplification, causal reductionism, and reduction fallacy, is a fallacy of questionable cause that occurs when it is assumed that there is a single, simple cause of an outcome when in reality it may have been caused by a number of only jointly sufficient causes. -Wikipedia

                                              1. 1

                                                Instead software might be a mere detail in the relationship between capital and a speculative endeavor of any kind?

                                                Many economics technology (generally) in this kind of way. See https://en.m.wikipedia.org/wiki/Technical_progress_(economics)

                                                Saying ‘mere’ implies a value judgement, however. Is software worth understanding in detail? It depends on where you stand.

                                                1. 1

                                                  Correction: ‘many economists view technology in this kind of way’

                                                2. 1

                                                  What progress have we made?

                                                  Is this a rhetorical question?

                                                  If you are interested in how much modeling in software has progressed, please dig in and share what you find.

                                                1. 2

                                                  I thought this a well written and easy to read article. However, I couldn’t help thinking that they should start with a simple website using Rails, Django, Laravel etc. Respond to technical requirements and demand, rather than build a solution for some imagined technical scenario in 5 years. That there is more emphasis on “how” it will work, than on “what” it does for users, is of concern.

                                                  1. 4

                                                    The confusion for many is not realizing that most mainstream programming languages have both a major, and one or more minor paradigms. See P. Van Roy and S. Haridi. Concepts, Techniques, and Models of Computer Programming, MIT Press, 2004.

                                                    There are few pure (single paradigm) languages, because as Gerry Sussman (co-author of SICP) says…

                                                    “Remember a real engineer doesn’t want just a religion about how to solve a problem, like object-oriented or functional or imperative or logic programming. This piece of the problem wants to be a functional program, this piece of the program wants to be imperative, this piece wants to be object-oriented, and guess what, this piece wants to be logic feed based and they all want to work together usefully.”

                                                    Consider for example, Java’s main paradigm is object-oriented, but it has both procedural and functional minor paradigms. Swift is the same. That Smalltalk supports procedural programming as a minor paradigm doesn’t mean that we call it a procedural language.

                                                    1. 1

                                                      Well, at the time the article was written, Java only supported functional paradigms as an experimental feature.

                                                    1. 5

                                                      Perhaps your discovering the sad reality that for much of our industry, experience has little value. The ability to solve problems quickly and learn fast on the fly is what is sought. Combine this with the general development methodology of “hack it till it works”, and you are left with anything but “craftsmanship”.

                                                      Perhaps the whole “craft” or “craftsmanship” perspective is misplaced? The challenge remains how to represent complex problems and systems as effective software, rather than a focus on how to be a “good” code linguist and proficient wielder of tools, libraries and frameworks?

                                                      1. 7

                                                        I think the problem is that everybody wants to be a craftsman but nobody wants to run a cabinet shop. That is, it’s quite easy just to focus down on the details of what you’re doing and seek perfection than it is to look up from your work and figure out why you’re here in the first place, why people pay you. That gets really complicated.

                                                        1. 4

                                                          for much of our industry, experience has little value

                                                          It’s true. We need to do a better job of collectively shepherding people to domains where experience is sought after in order to deter this from happening, however.

                                                          Combine this with the general development methodology of “hack it till it works”, and you are left with anything but “craftsmanship”.

                                                          You can do what I do and explicitly avoid all web development because systemic forces and ecosystems essentially impose layers of accidental complexities on you. This tack has benefited me, but the road less traveled is not easy. It’s only possible because I was somewhere that knew not to constantly drop web projects on me.

                                                          The challenge remains how to represent complex problems and systems as effective software, rather than a focus on how to be a “good” code linguist and proficient wielder of tools, libraries and frameworks?

                                                          This is an excellent summary and thinking point. Thanks!

                                                        1. 2

                                                          Why not just go back to all logic in database Stored Procedures? Have we as software developers learned nothing?

                                                          1. 1

                                                            Yes, I’m not sure there’s much new here. Maybe if coming from a less capable db?

                                                          1. 3

                                                            Perhaps it is worth pointing out that these “native” executables essentially wrap pre-jitted code into a convenient single file with fast startup time. These two features (single executable and fast startup time) can be attractive, but the price paid in most cases is runtime performance. In the majority of cases, dart code jitted against the VM will be more performant due to local type information and runtime optimization, which is (to a degree)) unavailable in a pre-jitted version.

                                                            Contrast the needs of a smallish command-line utility, versus a long running complex server application.

                                                            It should be noted that the AOT compiled code is always run within the context of a minimal Dart VM. In that way it is for many something different than “a traditional native executable”.

                                                            1. 7

                                                              “Software developers are domain experts. We know what we’re doing. We have rich internal narratives, and nuanced mental models of what it is we’re about, …”

                                                              For a large proportion of software undertakings surely this is not true. Much of software development is outside the domains of the computing and data sciences, and computing infrastructure. While popular to consider that these are the only endeavors of importance to today’s developers, the modeling of systems in domains other than these into code represents the majority of software running in the world today.

                                                              In these, we don’t know to model reliably and predictably, the systems that stakeholders (think they) want, and that external domain experts know. How can one consider applying scientific rigor to that?

                                                              1. 4

                                                                Great point. You are certainly correct that software developers are not always experts in the domains of their products. They are still experts in the domain of their tools and practices though, so they should be considered “domain experts” from the perspective of researchers.

                                                                1. 2

                                                                  They are still experts in the domain of their tools and practices though

                                                                  I like this degree of optimism, and hope one day to overcome my experience enough to share it!

                                                              1. 1

                                                                I suggest that an abstraction is a simplified representation of concepts real or imagined.

                                                                In the context of computer programming, it is the simplified representation of concepts real, imagined, or those already implemented in computer code?

                                                                1. 1

                                                                  “The biggest challenge is how to structure code so that its complexity stays manageable.”

                                                                  I disagree that this is the biggest challenge. Instead I contend that the biggest challenge is how to abstract or model a large, complex problem or system into working code.

                                                                  Maintainability is just one measure of quality of that effort.

                                                                  1. 1

                                                                    To some degree your “requirements” choices are limited by your software architecture. You mention it is a “CRUD” application. This likely means that your domain logic and constraints are in a Service Layer featuring procedural code wrapped in transactions. If so, then Use Cases or Stories are likely your best bet, despite their ineffectiveness largely due to them inevitably requiring further and further decomposition. They are particularly well suited to this “transactional script” approach, even though it so often results in a “big ball of mud” - as complexity and size increase.

                                                                    On the other hand, if you represent your domain logic and constraints in some different way …

                                                                    1. 1

                                                                      The author culminates with a statement of which is “better”. In programming languages there is no “better”, and to claim such is naive. There is only better “suited” to the particular problem or system to be represented or modeled.

                                                                      1. 3

                                                                        I’m looking into Flutter’s internals. Specifically more into how the widget tree gets initially rendered, then how only changed parts get updated, i.e. the widget/element/render trees, plus keys (local/global etc), and the relationship between Builder, StatefulBuilder, StatefulWidget and StatelessWidget.

                                                                        Anyone want to compare notes?

                                                                        1. 2

                                                                          I don’t have any notes to compare, but I’m just getting started with Flutter myself and I would love to read what you find if you have a blog or something.

                                                                          1. 2

                                                                            No blog on this type of stuff sorry. What do people use to collaborate together on a topic? Dare I say I miss something like Google Wave, i.e. a combination of collaborative wiki, question/answer forum?

                                                                            1. 2

                                                                              I miss Google Wave too…

                                                                          2. 2

                                                                            I don’t have any notes, but I remember the Xi editor guy recommending this talk about Flutter’s internals in his talk about Rust GUI: https://www.youtube.com/watch?v=UUfXWzp0-DU

                                                                          1. 10

                                                                            Given the title, I was hoping a little more for lessons learned, and some reflection of benefits/costs versus alternatives after one year, rather than largely being a description of what ES/CQRS is.

                                                                            1. 6

                                                                              Same here. The few folks I’ve talked to first-hand that tried ES/CQRS systems (a very small set size for sure!), ended up running screaming for the hills after a while (and/or doing a rewrite). Maybe they did it wrong, or maybe doing it right is hard? Unsure.

                                                                              So, I’d be sure be interested in hearing more anecdotes/stories/tales about how ES/CQRS went right, or didn’t.

                                                                              1. 11

                                                                                The few folks I’ve talked to first-hand that tried ES/CQRS systems (a very small set size for sure!), ended up running screaming for the hills after a while (and/or doing a rewrite). Maybe they did it wrong, or maybe doing it right is hard?

                                                                                ES is a quagmire like ORM (and really, OOP in general): never-ending domain-modeling churn, with the hope that a useful system is “just around the corner”.

                                                                                This stuff is catnip for…

                                                                                The context of the project was related to the Air Traffic Management (ATM) domain

                                                                                …government/defense contractors. The drones are obsessed with building and rebuilding the One True Hierarchy of interconnected objects. But taxonomy is the lowest form of work.

                                                                                According to Martin Fowler Event Sourcing:

                                                                                Ensures that all changes to application state are stored as a sequence of events

                                                                                Indeed, that sounds awesome. And in order to do that you need actual computer science (e.g. datomic), not endless domain-modeling.

                                                                                Domain Driven Design (DDD) is an approach to tackle …

                                                                                Like clockwork :)

                                                                                1. 2

                                                                                  Some great links in there, and some good reading. Thanks!

                                                                                2. 10

                                                                                  I have been working on an ES/CQRS system for about 4 years and enjoy it, but it’s a smaller system than the one the article describes. It’s a payment-processing service.

                                                                                  Because it’s a much smaller service, I haven’t really gotten into a lot of the DDD side of things. The system has exactly one bounded context which eliminates a lot of the complexities and pain points.

                                                                                  There was definitely a learning curve; this was my first exposure to that architecture. I made some decisions early on in my ignorance that ended up being somewhat costly to change later. However, I’ve been in this game a pretty long time, and I could say the exact same thing about plenty of non-ES/CQRS systems too. I’m not sure this architecture makes it any more or less painful to revisit early decisions.

                                                                                  What have the costs been?

                                                                                  • The message-based model is kind of viral. If you have a component that you could almost implement as a straight system service that’s just regular code called in the regular way, but there’s one case where an event would interact with what it does (example: a customer cancels a payment that hasn’t completed yet) the path of least resistance is to make the whole component message-driven. This sometimes ends up making the code more complicated.
                                                                                  • Ramping up new engineers takes longer, because many of them also have never seen this kind of system before.
                                                                                  • In some ways, debugging gets harder because you can no longer look at a simple stack trace to see what chain of logic led you to a certain point.
                                                                                  • We’ve spent an appreciable amount of time mucking around with the ES/CQRS framework to make it suit our needs. Probably still less time than we would have spent to implement the equivalent feature set from scratch, but I’ve had to explain why I’m spending time hacking on the framework rather than working on the business logic.
                                                                                  • If you make a significant change to the semantics of the system, you may need to deal with old events that no longer have any useful meaning. In many cases you can just ignore them, but sometimes you have to figure out how to translate them to whatever new conceptual model you’re moving to.

                                                                                  What have the benefits been?

                                                                                  • The fact that the inputs and outputs are constrained makes it phenomenally easier to write meaningful, non-brittle black-box unit tests. Like, night-and-day difference. Tests nearly all become, “Given this initial set of events, when this command/event happens, expect these commands/events.”
                                                                                  • Having the ability to replay the event log makes it easy to construct new views for efficient querying. On multiple occasions we’ve added a new database table for reporting or analysis that would have been difficult or flat-out impossible to construct using the data in existing tables. With ES, the code to keep the view model up to date is the same as the code to backfill it with existing data. For a couple of our engineers, this was the specific thing that lit the light bulb for them: “Wait, you mean I’m done already? I don’t have to write a nasty migration?”
                                                                                  • In some ways, debugging gets easier because you have an audit trail of events and you can often suck the relevant events into a development environment and replay them without having to sift through system logs trying to manually reconstruct what must have happened.
                                                                                  • The “dealing with old events” thing I listed under costs is also a benefit in some ways because it forces you to address the business-level, product-design question up front: how should we represent this aspect of history in our new way of thinking about the world? That is extra work compared to just sweeping it under the rug, but it means you’re never in a situation where you have to scramble when some customer or regulator asks for history that spans a change in product design.
                                                                                  • Almost nothing had to change in the application code when we went from a single-node-with-hot-standby configuration to a multiple-active-nodes configuration. It was already an asynchronous message-passing architecture, but now the messages sometimes get delivered remotely.
                                                                                  • And finally the main reason we went with ES/CQRS in the first place: The audit trail is the source of truth, not a tacked-on extra thing that might be wrong or incomplete. For a financial application that has to answer to regulators, this is a significant win, and we have had meaningful benefit from being able to prove that there’s no way for information to show up in a customer-facing report without an audit trail to back it up.

                                                                                  The main conclusion I’ve reached after working on the system is that ES/CQRS is a tool like any other. It isn’t a panacea and like any engineering decision, it involves tradeoffs. But I’m happy to have it in my toolbox to pull out in cases where its tradeoffs are the right ones for a project.

                                                                                  1. 1

                                                                                    Thanks for the comprehensive answer! <3

                                                                                  2. 8

                                                                                    Like with all Design Patterns, ES/CQRS is a means masquerading as an end, and good design will be found to have naturally cherry-picked parts of it without needing to name it as such.

                                                                                    Anecdotally, I’m dealing with a system that is ⅔ ES/CQRS and ⅓ bandaging together expanding requirements, new relationships between entities, increasing latency due to scale – basically everything that wasn’t accounted for at the start. It works, but I wouldn’t choose it over a regular database and a transaction log.

                                                                                    1. 6


                                                                                      As with outcomes, sadly so elusive.

                                                                                      It occurs to me that our industry would be well served with a “Glassdoor” for IT projects. One where those involved could anonymously report on progress, issues and lessons learned. One which could be correlated with supplier[1], architecture type, technologies, project size etc.

                                                                                      [1] supplier, e.g. internal or specified outsourced supplier i.e. Accenture, Wipro, IBM etc.

                                                                                  1. 12

                                                                                    While I find the writing of Martin Fowler to be good for getting ideas on new patterns or existing ones, better expressed, I strongly disagree calling this page a software architecture guide. Software architecture is a lot more than these patterns and approaches.

                                                                                    I’ve been building a few large distributed systems and been in the design loop of many more the past few years, within Uber. Software design/architecture of these systems resembled anything but what the articles talk about.

                                                                                    We did not use patterns or find the best architecture matches. Instead, we looked at the business case, the problem and the constraints. We whiteboarded, argued and discussed approaches, trade offs and short-medium-long-term impacts. We prototyped, took learnings, documented the whiteboard approach that made sense, then circulated the proposal. We debated some more over comments and in-person, then built an MVP, shipped it and went on with the same approach to the next phase, all the way to migrating over to the new system.

                                                                                    Nowhere in this process did we talk the kind of patterns this post talks about. We talked tradeoffs and clashed ideas all the time though.

                                                                                    Talking with friends in the industry, the same applies for much of the large systems built by tech companies across Uber, Amazon, Facebook, Google. If you read the design documents, they use little to no jargon, simple diagrams, little to no reference to patterns and are full of back-and-forth comments.

                                                                                    Maybe I live and work in a different environment than Martin Fowler. But where his thoughts of architecture end is where my world just about begins.

                                                                                    Also, as my view is so different on this topic than this post, I’ll likely write up my thoughts/experience in a longer form.

                                                                                    1. 6

                                                                                      I agree, what you describe is the way to go. You start with the business case, you think it through collaboratively, and you figure out the best plan you can for (a) getting it done, so that (b) you can maintain it with velocity from then on.

                                                                                      But I don’t think Fowler advocates anything against that.

                                                                                      I think, if you and some teammates were doing that, and Fowler was around, he’d be listening, understanding, and identifying patterns that he could document. Then he’d be remarkably good at explaining them to management and to the Product team. He also might overhear a conversation and say, “We struggled with that at xyz. Here’s what we did.” And he might even point to one of his own articles in that case.

                                                                                      I think what often goes wrong is developers often start with a blank whiteboard, panic, and then grab Fowler’s or some other author’s works, and try to make them fit.

                                                                                      Rather, the process should be: start with a blank whiteboard, think hard, sketch out some ideas and identify challenges, then maybe see if any documented patterns or ideas might help.

                                                                                      1. 3

                                                                                        Do you ever retroactively try to identify what architectural patterns you ended up with, for instance to mention in documentation? In the end I would say patterns are mainly useful as a convenient shorthand to communicate parts of the design, more than a toolbox to try and apply.

                                                                                      2. 5

                                                                                        Maybe I live and work in a different environment than Martin Fowler.

                                                                                        This touches on something I’ve been thinking about for quite a while. That there are broad categories of sofware application, and that programmers typically have a perspective only on those they have actually experienced. I’m not talking here in your case, but more generally.

                                                                                        For many new in the industry, there is a perspective that software is limited to problems in the computer and data sciences, and those involving computing infrastructure. Often these undertakings have a focus largely on what may be considered non-functional requirements, where functional requirements (and how to represent them in code) is of relatively little importance. Issues such as how to scale, be reliable, available, accessible and so forth are paramount.

                                                                                        On the other hand, there are a large proportion of applications where how to model a complex problem domain into code is the issue. Typically a problem domain where expertise is outside of the development team. How to discover, manage and implement functional requirements into code is the core issue. It is this later world that Martin Fowler primarily lives in and writes about.

                                                                                        Is such a categorization of any value?

                                                                                        1. 2

                                                                                          Possibly, but the example you give sounds to me like it intermingles the datamodel / domain structure / domain architecture with the software architecture, while the former, in my view, is mostly one of many constraints on the latter and one that can be used to ‘encode/compress’ part of the functional requirements. However, you can’t design a good software architecture without taking all functional requirements into account, while at the same time you also need to take all other requirements into account: after all, there is only one software architecture.

                                                                                          1. 1

                                                                                            I think this is a good categorization.

                                                                                        1. 2

                                                                                          Here are my thoughts. I’d be curious to know what others think of them?

                                                                                          Perhaps the question of what is Software Architecture can best be considered through what a Software Architect does.

                                                                                          That role (which may or may not be a formal one in a particular Project), makes decisions about how requirements should be implemented in a software solution. In addition, a Software Architect may make decisions about how those requirements are discovered and managed.

                                                                                          In this regard the role can be considered to be the technical complement in a software project of decisions made by a Project Manager, which typically involve those related to the management of scope, units of work over time, milestones, resources, cost, stakeholders and risk.

                                                                                          It is common that these architecture decisions are limited by constraints, which can be typically considered to be already made decisions or requirements which limit the choices of the Software Architect. Examples of constraints include:- functional requirements must be represented as Use Cases; the corporate Oracle database must be used for data persistence; the solution must be be Sarbanes-Oxley compliant etc.

                                                                                          Decisions include those related to both functional and non-functional requirements (subject to constraints). There are a large number of ways functional requirements might be discovered, managed, represented and implemented. A good Software Architect knows the relative merits and deficiencies of different alternatives when applied to differing requirements and circumstances. Likewise, one should know (or delegate to one/those that know) the relative merits and deficiencies of alternative decisions related to non-functional requirements which may include those related to:- maintainability, scalability, reliability, usability, security, compliance etc.

                                                                                          While the Software Architect role may not formally exist in a software project, consider that the role is always actually performed. How such decisions are made, and when they are in a non-trivial undertaking, are directly related to a project’s success.

                                                                                          Given this, perhaps consider that a software architecture is the result of decisions made to meet the software’s requirements and constraints. These results can be considered the software’s architecture.

                                                                                          It might be useful to consider this against another domain …

                                                                                          Consider that a building or bridge architecture is the result of decisions made to meet the structure’s requirements and constraints. These results can be considered the structure’s architecture.

                                                                                          1. 1

                                                                                            My article intentionally focuses on the software architecture instead of the architect. There are so many things an architect should do that it hardly fits into a blog post. My employer has a 10 page document. An example would be that the architect should influence the organization because Conway’s law.

                                                                                            I would say that the primary role of an architect is to ensure that the software architecture is designed intentionally. The assumption is that an intentional design is better than an emergent architecture with respect to whatever metric the business desires.

                                                                                          1. 3

                                                                                            How refreshing to read of a real problem and journey to an (alternative) solution, rather than yet another general description or critique of a technology or technique. Many thanks to the author.

                                                                                            It’s particularly fascinating for me because I work in a different world of complex line-of-business systems, which do not often involve problems like how best to implement (and persist) a very large graph, where one has requirements for fast and concurrent access with consistency constraints. That being said I have been involved in a couple of systems that incorporated “engines” that faced some similar issues. For example, a large estimation system that maintained a complete parts list for vehicles in order to calculate the cost of repairs (including the time required for repair), another being part of the calculation engine for an actuarial application, and a complex aircraft engine management system.

                                                                                            Would have been nice to have read of your experiences before working on the architecture of these!

                                                                                            1. 2

                                                                                              Thanks, Aryeh.