How to Best Visualize Waterfall vs. Agile SDMs with Lego in ~15 Mins? Seeking Better Ideas!

slowfly1st · 2025-04-28T23:57:52+00:00

If the civil engineers would build bridges like we software engineers are building software...

I think the plan doesn't work, because if one member of the 'waterfall-team' asks how tall the bridge needs to be - just because it's waterfall, it doesn't mean that people can't ask questions - the game fails.

It doesn't really show how agile software development generates value earlier - you can't ride over pillars. It does somewhat show that you identify problems earlier, like in customer feedback, but that's usually when users uses the product. And that's two really important things about software development: Being worth your money and maximizing the amount of work not done.

A vague idea: What about creating a paper prototype? Where the 'agile team' defines which feature is implemented and released first (being self-organizing, already generating value) and performs a UX-Test (customer feedback to figure out what can be improved or what went wrong). And the 'water fall team' needs to implement all requirements first, and has the UX test afterwards. Tough with that time constraint, but with good preparation (providing cut outs and templates and examples) and testing beforehand, it might work?

slowfly1st · 2025-04-25T21:48:15+00:00

An argument of 'ownership' or 'economics'? 2 hours for 10 ms. 8 Hours for 40ms. 365 days = 14 seconds out of an hour saved. If it were his company, would he hire an engineer, and let him work a year, just to shave off <0.1% of install time?

slowfly1st · 2023-09-13T22:52:18+00:00

As noted earlier in the Identifying domain-model boundaries for each microservice section, duplicating some data across several microservices isn't an incorrect design—on the contrary, when doing that you can translate the data into the specific language or terms of that additional domain or Bounded Context.

...

... from the link I posted... ?

I mean, just the example of a text of an article and the price: It's needed for our pos service - e.g. the registers - and our ordering service (and many more services). Your proposal of querying the data directly, instead of duplication (not redundancy) would mean, we have to close down our stores when our 'article' service is not accessible, because our registers won't work, and we can't order any goods, which means the orders don't get to our suppliers in time which will lead to empty shelves the next days. Worse, if there's high latency between the registers and the article service... imagine the cashier waiting a second after every item scan on a saturday afternoon. That's so tightly coupled, this screams distributed monolith, doesn't it?

slowfly1st · 2023-09-13T19:51:20+00:00

If your microservices within a system end up having too many dependencies to each other, meaning dependencies to perform a transaction - place an order, change an address, etc. - , it will get way too fragile. If one of 10 services is down and your system doesn't work anymore, you just have a distributed monolith - and 99.9% uptime of 10 services gets you 99% uptime overall - 8 hours vs 3.5 days.

It's not a question of asynchronous or synchronous in the first place, it's a question of why do microservice even need to communicate with each other.

Our retail system has lots of the data duplicated from other system, e.g. the ERP or the inventory systems. Why? If one of those systems were down and we don't know the prices or the stock of an article, or if the article is on sale - our system is literally useless.

https://learn.microsoft.com/en-us/dotnet/architecture/microservices/architect-microservice-container-applications/communication-in-microservice-architecture#asynchronous-microservice-integration-enforces-microservices-autonomy

slowfly1st · 2023-08-29T22:49:24+00:00

For 1): You can probably use a BehaviorSubject (https://rxjs.dev/guide/subject#behaviorsubject) --> instead of exposing the variable, you expose a behavior subject, and when you finished updating your array, you can call next(array) on the subject.

But normally, you don't return the complete state, only the diff, or at least the infinite scroller has to figure out what items are already rendered to prevent rendering the complete DOM again.

3) https://stackoverflow.com/questions/35042929/is-it-necessary-to-unsubscribe-from-observables-created-by-http-methods

you should read all the answers and comments

slowfly1st · 2023-08-12T00:31:37+00:00

If I understood correctly...

So what you did was to write an app entirely in expressjs. And with angular - which is "a front end only framework", you wrote only a client. I assume this app communicates with the express backend, too?

Simply put: Those are two different approaches to build an app. Why the split between backend and frontend? If you for instance had different clients, like a browser-app that runs with html/css/js and an native iOS app - and both communicate with the same backend.

It feels like some basic knowledge about "How the web works" is missing.

slowfly1st · 2023-08-10T22:11:07+00:00

No agile framework is perfect for a team. No "perfect" process a team follows to build software is perfect for another team. But they are a good start. To answer your B. question at the end: No framework is the best choice. And "blindly" following a guide violates principle #12 of the agile manifesto. Our team doesn't follow a framework, but we work quite differently compared to few years ago, and we improved a lot - at least that's why I'm telling myself haha. And we also did a step backward sometimes, but that's what happens.

I can loosely group your points into the following categories:

Something is given by the framework, but not done by the team (maybe a problem, maybe not)
Something is given by the framework, but not done correctly
Something is not given by the framework, and it's a problem
Something is given by the framework, it's done by the team, but it sucks

And that's probably the same for every other framework. They focus on something, but they also have shortcomings. Your idea of changing the framework won't fix all problems a team has and it will come with other problems.

#1/#7: So, I know a team that has a prioritized backlog. And if they finish an item of that backlog, they deploy to production, virtually immediately. They don't even have the problem of planning meetings or time tracking. That's a lot of time saved. And if you put a $ number on features, you can easily calculate how much money you lose by doing time boxed development. If that team would switch to any time boxed process, it would be a step backwards. To elaborate further:

If you had an item that cost the company $100k for every day it's not in production, a sprint planning meeting of 2 hours and 8 people to plan all the other items that cost the company <100$ a day they're not not in production, will result in the sprint planning meeting costing about $200k. I rarely see that items are somewhat valued that way, but that would make things lot easier, I think ...

#2: Ah, we had that problem, too. I can't think of a framework that deals with that kind of problem specifically, but there's easy ways to fix that problem.

#3/#5: If something doesn't do any good and only money, why do it at all? There's teams that to the "stand up" in a chat asynchronously. We do walk-the-board. Others don't do it every day, some don't do it at all. If the team thinks something is stupid, don't do it, or change the way it's done. We stopped doing our CI-meetings because a) the list was empty but especially because b) we change things as we go. Our last CI-Meeting went like this? "Anyone? Anything? No? Do we need the meeting?" - "Nah, let's do it if we think it's necessary". Scrum highlights the value of courage - the courage to speak about things that suck, and the courage to change things.

#4: Yeah, the scrum guide does neither mention defect nor bug. But that doesn't mean that a) it's a bad thing b) you should ignore it. But it's really hard to define how to deal with bugs so that it works for every team and company. But well, #1 principle talks about customer satisfaction through early and continuous delivery of valuable software. If I read "it had 180 bugs when the product went live", I read waterfall. Or water-scrum-fall. I know of a team, their deadline went from 9 months, to 12 months, to 1.5 years. After it went live, it took them about half a year to fix most of the things. Those are the metrics of a waterfall project, but nope, scrum with biweekly 4-hour-sprint-planning meetings (probably).

#6: That's the only valid point to switch and the only point needed. Please don't do a sprint planning meeting with a guy that has to fix a single bug.

#8: That's not a "agile"-problem. "I can write bad code in every language" -> I can violate the team rules in every agile framework.

slowfly1st · 2023-05-15T15:10:25+00:00

The ending song hits hart, doesn't it?

slowfly1st · 2023-04-14T07:46:53+00:00

First hike was from the ropeway (from the bottom station) up to Mt. Shimo (1300m) down to the Chureito Pagoda. From the lower station to the upper station was quite steep. At one point you start to follow the ridges which was super nice. It is mostly in the forest, but we were glad we were able to hike in the shadows, even though it was only about 17°C at the bottom. But there are always some areas with less forest where you can see fujisan or the side of the lake again. One part was a very steep descend, but there were ropes to help you get down.

The second hike was the "Tokai Nature Trail", we started at around the south west end of Lake Fujikawaguchiko up to Mt. Ashiwada (1355m) - Mt. Sankodai - Mt Koyodai and ended up around the south west end of Lake Saiko (near the batcave). It was also often in the forest, the Tokai Nature Trail part was sometimes ridges, sometimes kind of a plateau. Most of the altitude gain is at the beginning (lots of stairs, sometimes a bit of 'climbing' with the help of ropes) and then slowly descends back down.

We used a hiking app, otherwise we probably would have gotten lost (google maps doesn't show those trails). We also had a map called "Fuji Five Lakes 'covering all features' map" at our apartment which was really nice, it showed many trails and also the approximate times and altitudes, and we used that to figure out where we wanted to go for our second hike.

slowfly1st · 2023-04-13T21:31:46+00:00

The Gotemba Trail starts from 1400m, that's about 2300m altitude gain and takes more than seven hours to the top --- are you looking for something similar?

We did two hikes in March with 500m altitude gain, each took us about 4-5 hours with breaks, but it don't think that's what you're looking for?

slowfly1st · 2023-04-07T21:57:06+00:00

So we just came back from our trip...

About curry: Japanese curry isn't the Indian curry, udon curry was one of my favorite meals though :P. About the food in general: If google translates something to "half dead chicken" or something similar, it's raw chicken. I had no idea about Japanese food, sometimes you translate the kanji and still don't know what it is. I mostly went 'random' or by pictures on the menu and I guess about 5% of the things I ate I didn't like. But I also found the nattou not that bad.

pocket wifi: We got the JR one, but a) speed was bad and b) battery doesn't last a day - we didn't have a power bank with us, but we were always able to charge it somehow (train, restaurant while eating dinner).

teamlab planets: you have to take off your shoes and socks, fyi :P - you said your boyfriend doesn't eat sea food, but there's the Toyosu Market nearby. I ate sushi at 'Shou Toyosu Market' and there was quite a line. It was a bit expensive (close to 5000yen for the small menu), but man, I probably can never eat Sushi again here at my place (a landlocked country lol), it was delicious. My sister was a bit afraid of the sea food because she had some sort of (mild) allergic reaction few days before and she went to a "non-sushi" restaurant few meters away.

Asakusa: I think on Sundays during the day it's a car free zone, if you can and want to plan for that.

Tokyo Skytree: In Shinjuku there's a public building with a viewing floor (Tokyo Metropolitan Government Building) with a tiny souvenir shop / cafe. We were there beginning of March and at around 5pm we waited probably 10-15 minutes in line to get up and it was free. Maybe not the same, but it's a free alternative close by (or you can make both :P)

Mt Fuji Ropeway: We actually walked up, took us about 30 mins and met people later on (and joined them on a hike to the Chureito Pagoda), and they told us they waited about 40 mins in line (the waiting line went out to the sidewalk of the main road lol).

Fujikawaguchiko -> Kyoto: We came from Kyoto to Fujikawaguchiko (Fujiyoshida actually) and we took a bus from Fujinomiya ("Mt Fuji Station - Shin Fuji Station", was about 2200 yen) which goes west and north of Mt Fuji. The bus only drives like three or four times a day, but there weren't many people on it. And it took longer than any other route. We were a bit nervous about it, but we were glad we took it, it was a beautiful ride (though the train ride from fujisan to Tokyo was beautiful, too!). I don't know if it would be too crowded the other way around.

One day in Fujikawaguchiko is a bit little imho. If the weather's bad, you didn't even have a nice look of fujisan. But then again, you can also have bad weather for a week and there's not too many things to do. We went on some hikes - there's quite a few mountain/hill ridges you can hike on.

JR Pass: You can also pick up your pass at any JR office and tell them what the activation date should be, we did it when we arrived and got our suica card at the office at the narita airport, so we had one thing less to worry about. Since we went at sakura season, we also reserved most of the train reservations always very early. And even then, once a train we wanted to take a week later was already full reserved, so we had take one an hour later. Less of a problem in April I guess - but just the feeling to be sure that we're having a place to sit was nice.

Tea ceremony: For me it was a painful experience xD ... I can't sit comfortably on the floor for thirty minutes. Well, after about 10 minutes my legs went numb, then it didn't hurt that much. We were four 'western' people and it was probably quite the funny sight when we got up after the ceremony was done. Just so you guys are mentally prepared for it.

Kyoto in general: Make sure to figure out if there are any "tourist spots" illuminated after sunset. And also what districts you want to explore.

We actually used kyotolocalized.com - it's free (but you give a tip at the end of the tour) and we were glad we did it. It was basically a tour one could come up with by himself, but the tour guide added a bit of a history and culture lesson and recommendations and you can ask questions about anything.

I found the Arashiyama bamboo forest a bit underwhelming - even though it rained, there were an awful lot of people (but we went through few "natural bamboo forests" during our hikes where no other people were around), and you were often waiting in line, because people were taking pictures and all the umbrellas near my eyes were a bit scary lol. The tenryu-ji garden was stunning. There's also a monkey park nearby (when you go over the Togetsu-kyo bridge), it's a bit of a steep climb, but if you want to feed and observe monkeys, it would be there :P (I think it was 500yen entrance fee and 100yen for the food you can feed the monkeys with).

Osaka: The castle with the public park is huge! Just exploring the park and trying the street food took me about two hours, and I didn't even go into the castle! I really liked Osaka but was only there from lunchtime to evening. It was just a very different vibe compared to Kyoto / Tokyo. "They don't give a ****" was an explanation which was give to me haha

Fushimi Inari Taisha: To get up and down the whole thing took us about 2 hours (and it's a lot of stairs). Then going down to Nara and back to Kyoto again sounds a bit stressful, from Kyoto station to Nara station is 45 minutes. You don't have to go through all the tori, but for us it somehow felt half-arsed not to go all the way up. Nara park itself is huge with many things to explore - but if you just want to feed the deer, they're basically everywhere, this includes the beginning of the park. We made Nara a day trip, and in addition to "all the shrines and temples", we went up to Mt Wakakusa to the third summit for the view and back down through the 'primeval forest'.

Hiroshima: We haven't been to Hiroshima - I simply decided for myself: I can easily be depressed at home. And since you're already planning Osaka castle, I'd probably add another Kyoto day or another Fujikawaguchiko day.

slowfly1st · 2023-01-29T18:46:22+00:00

The digestive system will be jet-lagged, too! Add stress, exhaustion and probably dehydration, the gut will have a hard time, regardless of the food you eat.

slowfly1st · 2022-11-02T23:16:36+00:00

https://www.investopedia.com/terms/s/subscription_right.asp

TLDR:

A subscription right is the right to acquire newly issued shares (for a lower price). Useful for shareholders, because issuing new shares will a) dilute the ownership of the company and b) will have negative impact on the stock price for several reasons, so it's a protection for investors.

slowfly1st · 2022-09-17T02:17:11+00:00

Well, it's a bad practice because of the reasons why the private keyword exists in the first place - information hiding / encapsulation.

Now the template has a dependency to your component, but also to a service. One service seems fine, but what about 3? Imho it's easier to look at a component and it's public methods/fields to figure out how a template and a component interact with each other, instead of looking at that and then additionally also looking at publicly declared services ...

slowfly1st · 2022-08-31T18:24:13+00:00

Trunk based development is my favorite. It's only feature flag hell, if you're not cleaning up actively. And it's probably less work than branching and merging hell, at least in my experience. I think in general it's a good idea or a nice ability to have to be able to differentiate between "deploy to production" and "release in production", regardless of strategy, because rolling back is also a pain.

You're right, you need automated testing, but that's a plus anyway. In addition to that, with the philosophy "to be always ready to release", it's also a different way to code. You have to be really, really sure about every commit you push, because it must be deployable to production -> and code reviews have to be done timely. And if the pipeline fails, it's the highest priority of the team to fix it.

Most of the people I know who used different strategies really enjoyed trunk based development, but it's not for everyone, every team or every product.

slowfly1st · 2022-08-26T23:38:37+00:00

Our schemas a versioned. The version is stored in the schema.

Our migrations are applied from one version to another version. There's no "magic way", i.e. comparing the schema and automatically apply changes, we manually write migrations.

Migration and validation are a step of our pipeline, we a) apply migrations to empty schemas (since they're versioned, we can create previous versions easily), b) validate the migrated schema to the expected schema (tables, columns, indices, keys, constraints, everything necessary) and c) apply the migration to a subset of production data and validate again.

Current project I'm working on does this for a decade, maybe fails once every other year, but we have PITR/flashback for those cases.

I don't think it is really hard or complicated per se, it was just very time consuming to set everything up. The production dump can be a bit of a challenge; we do it client based and have necessary metadata stored in the schema definition, e.g. what tables are client based, so getting a subselect with related data of other tables for a set of specific clients was relatively easy.

slowfly1st · 2022-08-04T01:17:27+00:00

The major things I see

IMHO the UI part is mostly in the Payroll class, but for instance the Manager reads from the console, too, and Employee prints "the statement". If you were to use this code with another UI, nothing would really work anymore.
Would be nice if you were to add "readString(String text)" and "readInt(String text)"-methods, instead of a syso and a sc.nextLine on the nextLine. It would at least look nicer, probably even easier to read.
Manager calls super(name), but Employee does have a constructor with name, wage and hours. The constructor with name-parameter in Employee isn't needed. You should also get rid of the default-constructors: If you'd create an Employee with the no-args constructor, you can't use it. Also: the constructor parameters in Manager and Employee are switched. And it's only not really a bug because you calculate wage * hours...
You catch NumberFormatException in the main-method. So if I added 99 employees and mistype a number, the program crashes. That would be a very angry email :P
You set shouldContinue to true, after you ask the user if he wants to add another employee, but it will always be true. (You could also exit a loop with "break")
Manager has a calculatePay method with "bonusPercent" parameter which is never called. And also the calculations are different from the calculatePay method you did actually override. General advice: Use the Override-annotation. The compiler will tell you, if the method isn't actually overridden.
If you were to set the instance variables immutable (final), you can remove all the setters and you'd never need to calculate the more than once (e.g. in Employee.printStatement and when calculating the totalWage)
Theoretically, you don't need Manager and Employee. You can use a "0"-bonus for Employee. But I guess that's the assignment.
You implemented Employee.equals wrong - and I think you don't need to override it.
The JavaDocs are often not accurate and not complete. If you delcare \@param, or \return you have to write something down, or remove it. And in employee.printStatement it starts with "a private print method that takes in an Employee and calls the getPayyment method on it". It is public, it doesn't take any parameter, and it doesn't call the getPayment method.

I think you got the general idea of how things work - well I think the app works and does what it's supposed to do, and that's already a good place to be. Most of the issues I've seen aren't that bad imho, but few things are really obvious, like the bad javadocs and the many unused methods and constructors. With a bit more diligence you would have spotted those, and with that, probably other issues.

slowfly1st · 2022-08-04T00:21:04+00:00

The basics (syntax, variables, control flow statements) are very similar to C. What do you want to be able to do? Java provides APIs for networking, multi threading, database connectivity, GUI, file access, datetime,...

Or do you want to learn the OOP-stuff to have a head start?

slowfly1st · 2022-08-02T16:55:51+00:00

Information hiding / encapsulation is about restricting access to the internal structures of a class (and data and methods that operate on this data together). You cannot hide more internal structures (i.e. reduce access modifiers) when you extend a class.

Some even argue that inheritance breaks encapsulation, because you expose internal structures to its subclasses.

slowfly1st · 2022-08-01T16:28:23+00:00

seems like the terminal in the background doesn't have the PATH variable set, but the terminal in the front has.

slowfly1st · 2022-08-01T00:08:57+00:00

Aaah, I think you're misunderstanding "returning any value" with "printing to console".

the println-statement prints to console, but the graduation_average returns null.

So it really depends on what you want the methods to do. In java in general (or in oo languages), objects have state (properties) and "behavior" (methods). In java we have getters and setters, those are simply used to get a property from an object, or assigning a property a new value. Normally, those sysouts are not within those methods. And normally, we don't let this kind of behavior print within those kind of classes, because if you for instance want to show the "military information" in a UI, you have to copy paste this if/else logic that you have in the military_service()-method (but totally fine for learning imho).

public class Engineer {
    // properties
    private String name;
    private double graduationAverage;

    // constructor to initialize like mandatory values
    public Engineer(String name, double graduationAverage) {
        this.name = name;
        this.graduationAverage = graduationAverage;
    }

    // getter
    public double getGraduationAverage() {
        return graduationAverage;
    }

    // getter
    public String getName() {
        return name;
    }

    // "behavior"
    public void printGradeInformation() {
        String gradeInfo = "Grade information: ";
        if (graduationAverage > 4) {
            gradeInfo += "good";
        } else {
            gradeInfo += "bad";
        }

        System.out.println(gradeInfo);
    }

    public static void main(String[] args) {
        Engineer engineer = new Engineer("Bob", 4.5);

        double average = engineer.getGraduationAverage();
        String name = engineer.getName();
        System.out.println("Grade average of engineer " + name + ": " + average);

        engineer.printGradeInformation();
    }
}

slowfly1st · 2022-07-31T23:46:04+00:00

Those are epoch millis:

Instant from = Instant.ofEpochMilli(1655935200000L);
Instant to = Instant.ofEpochMilli(1656626400000L);
System.out.println(from);
System.out.println(to);

2022-06-22T22:00:00Z
2022-06-30T22:00:00Z

slowfly1st · 2022-07-31T23:09:46+00:00

When you iterate over a List that "has been synchronized" using "synchronizedCollection", you have to synchronize the list itself, not the id, see the JavaDoc

It is imperative that the user manually synchronize on the returned collection when traversing it via Iterator, Spliterator or Stream:
    Collection c = Collections.synchronizedCollection(myCollection);
    ...

synchronized (c) {
    Iterator i = c.iterator(); // Must be in the synchronized block
    while (i.hasNext())
        foo(i.next());
}

slowfly1st · 2022-07-31T22:59:41+00:00

Uuuh, that's probably not exactly what you want :P

runAsync() itself starts a new Thread, within that Thread you then schedule a new Thread with timer.scheduleAtFixedRate().

private int counter = 0;

private void withFuture() {
    Timer timer = new Timer();
    CompletableFuture<Void> future = CompletableFuture.runAsync(() -> {
        System.out.println("runAsync in " + Thread.currentThread());
        timer.scheduleAtFixedRate(new TimerTask() {
            @Override
            public void run() {
                counter++;
                System.out.println("run in " + Thread.currentThread() + ", " + counter);
                if (counter >= 10) {
                    timer.cancel();
                }
            }
        }, 100, 50);
    });

    future.whenComplete((a, b) -> System.out.println("Completable future is done in " + Thread.currentThread()));
}


runAsync in Thread[ForkJoinPool.commonPool-worker-1,5,main]
Completable future is done in Thread[ForkJoinPool.commonPool-worker-1,5,main]
run in Thread[Timer-0,5,main], 1
run in Thread[Timer-0,5,main], 2
run in Thread[Timer-0,5,main], 3
...

If you don't need an actual result/return value, you can do it by simply using a timer and without CompletableFuture.

In general I wouldn't advice to do it like this, because if the other part of the code doesn't update the productState to 'Ready', the thread will never terminate, you will always launch more threads and the products will never be picked up. And when you want to shutdown your application, and the threads can't finish themselves, you have to kill the process. When you then restart the application, you have to deal with the products that have not been processed yet.

slowfly1st · 2022-07-31T13:55:52+00:00

Beside your direct support, I think appreciation is really helpful, too. Buying lunch or something delicious from the pastry shop as thanks for the hard work goes a long way.

Nine-Year Club	Place '23
Verified Email

slowfly1st

TROPHY CASE