Okay. The equivalent at the single voter level is if a voter is undecided between Candidate A and Candidate B. After much contemplation this voter decides she's 50.5% in favour of B and 49.5% in favour of A, so heads to the polls to cast 100% of her single vote for B.
Haha, reminds me of 20 years ago when someone said they are building a PHP app from scratch and this time they won't have HTML, business logic and SQL all in one .php file. We learn as we go ;)
Brilliant idea, thanks. I thought my 2 hour walks were long (and beneficial). I need to try doubling that, then doubling that, then doubling that again.
Wow, that's a somewhat rare edge case. Let me see if I can beat that (hold my beer): 5. Astronauts for Boeing Starliners who are not certain when their return flight will be.
I live in a boating town and there's a whole line of houseboats in one of the marinas, the others have plenty of boats that people seem to be living on board. No property taxes and the marinas always have bath/shower (and sometimes laundry) facilities; portable relatively efficient refrigerators now exist that can be either shore or battery powered, etc.
Undoubtedly, some of these rent storage facilities.
I think he meant that open source third party add-on packages for .NET were basically non-existent. Not .NET itself. Your "_almost_" qualification has me concerned. Over the decades I've almost been fooled many times by Microsoft's claims of being open and/or interoperable only to find out that it's "almost".
Ba-humbug! Hosting at home on a server purchased from a vendor like Dell? That's not true self hosting either. A true Scotsman self hosts on hardware he soldered up himself. /s
Exactly this! I recall a large survey of SAP deployment projects in the late 1990s. By far the most successful consultancy, out of Chicago I think it was, had it written in their contracts "you'll change your business processes to match SAP; not SAP to match your existing business processes" (more or less). By turning away clients who could not accept that, they had happy clients, happy employees (little burn out), and no runaway costly never-ending death march projects.
There's a bit of selection bias going on there though. The reality is that SAP and similar products are designed for a business that works a certain way, and so obviously businesses that fit that profile are most likely to get value from using the tool. However, there's a reason other businesses don't work that way, and often retooling to work the SAP would be a net negative. Sometimes retooling SAP to fit the business is also a net negative, in which case the right choice is just to not use SAP, but I've certainly observed cases where there was a benefit from refactoring the tool to fit the business.
On "retooling SAP": SAP deliver their systems with all source code and dev platform included, and that may help convince some customers to go for SAP.
However, those that embark on deviating from the well-trodden path are going to be in trouble soon: after every update, potential changes made need to be re-done or edited or at least tested. So as the parent suggests it's really better to adjust the business process if you can.
> So as the parent suggests it's really better to adjust the business process if you can.
That's another way of saying that there are serious trade-offs going that way that need to be justified... which may also be true for the path of adjusting the business process.
There's a ton of variety out there in the real world such that you'll always find a few businesses that match almost any scenario you can imagine. So, yes, for some business doing a process a certain way is a competitive differentiator or advantage ... or even a necessity for their particular industry. For these businesses banging the SAP square peg into their special BP round hole is worth attempting. Even better might be just building their own custom round peg. I'm suggesting that many (not all) businesses are doing a BP a certain way for no compelling reason whatsoever other than that's the way they (almost randomly) picked to do it decades ago and could easily change to a standard practice without loss of competitiveness (maybe even gain by focusing on what does).
> There's a bit of selection bias going on there though. The reality is that SAP and similar products are designed for a business that works a certain way
ERP products are designed following "standard" or "best" practices/processes. It's common to see companies first contract a consulting company to "re-design" their processes before they then try to implement an ERP system.
...and yet there are all kinds of segments where customized tooling is more the norm than otherwise. It just depends on whether the deviation from the norm is a competitive disadvantage or a competitive advantage. There are a lot businesses where in at least one case, it is an advantage.
That's just days it's visible to be selective in your customers, not that all businesses have the same processes or would be better off not customizing.
Agreed! There's waterfall & agile and dogmatic & pragmatic. I've never worked on a dogmatic waterfall project but have worked on several dogmatic agile projects (that made me strongly wish I wasn't).
In the pragmatic waterfall projects I worked on, during the Design phase there was still coding (by juniors, on submodules with obvious predictable designs as well as some refactoring (yes!)) and testing going on. It's just that in the Design phase it was understood any coding might need to change. In the Code/Build phase, design changes were still possible as issues were discovered (with maybe just a little more resistance). In short, we were very pragmatic about it. Much more so than with the Agile religion.
The Design phase focused on designing but not exclusively so. The Build phase focused on building but not exclusively so. Humans were building things long before Agile came along. The pyramids were probably built with a pragmatic waterfall method, not an agile method (pragmatic or dogmatic).
Hardware development is almost exclusively Pragmatic Waterfall. It's pretty much a requirement. Lots of reasons. Too many to list here (it would probably not be useful).
As a software dev for hardware companies, most of my life, I splashed in a lot of waterfalls.
One reason that waterfall method I mentioned actually managed to produce a working system was that the customer (together with all the companies working on the project) put extensive effort into the requirements phase. Working on the requirements and removing requirement conflicts (a very common thing), understanding of requirements, feasibility of requirements etc. etc., and, at the final stage, a week-long meeting with everyone (customer, companies) to work out the last kinks. Only after that did the next phase start: Creating software requirements from the system requirements, and from there, an architecture and so on. And, as this was something involving many companies in many countries and even continents, having everyone on the same page was essential. And it did work. Of course in the years following the project there would be bugs etc, but not fatal ones (which are typically caused by errors in the requirements- and architecture phases).
(We had several projects of the type above, and those which had more problems were those were the requirements phase wasn't as extensive)
EditAdd: Just to be clear - I don't think the pure waterfall model is the best way to work. However I did learn a lot from it, particularly how important requirements are. And the forth-and-back-and-forth-and-back on this which can happen in Agile projects isn't really the solution either.
It works if your client knows and can articulate exactly what needs to be made.
I imagine that was more common in the 80s and early 90s when most people working in computer land were more tech savvy (relatively) than your average project manager today. And the market was less “get it out there asap” than it is today.
reply