Programming

My last role had no paradigm, conflicting inputs from multiple people you had to work with vs your management, and God help you if you prioritized one over another.

I’ve also been in roles where I “supported” people who were using an agile+waterfall hybrid, and my role included keeping an eye on their 6-12 month plans and making sure the backend things they would need would be ready when they’d need them, with the gentle understanding that they may not know what they need.

I’ve never seen a Scrum “team” that actually follows Scrum. Ask me about hour-long daily standups!

My company does a mix of scrum and kanban, but its all pretty loose. I suspect its actually very rare to find any of those development models being followed strictly, once you leave uni you'll end up doing whatever the company/team you join does.

I've spent the last 25 years writing enterprise applications. 10 or so years ago the sdlc became "Dark Scrum" where all the trappings of scrum, expectations of waterfall and non of the prep work of waterfall. It's an interesting system where management can demand anything and then blame the devs for any and all problems that occur because "we didn't follow the process". Recently I've been given a larger management role and kind threw the entire process out of the window. Baby, bathwater, all of it. And just went with a basic kanban style. We try to do one thing at a time and a lot of my time is spent keeping a backlog that is estimated and prioritized. We have a standup type of call on Monday and Thursday for no more than 5 minutes. (we're a 100% remote team now, so no office)

The paradigm in my work life I followed most of the time on most projects is "do whatever the project manager decides is important at the moment". I'm not aware of it having a particular name. Technically, they might call it scrum or something else, but really it's not even close to any of these labels. It really was always just "whatever sounds good to them at the time". I guess you could call it "agile", but not by choice necessarily. Please ask more questions on this or provide more options for me to choose if you want a better answer.

On my personal projects, I follow the "start programming and see what comes out at the end of it" paradigm, I'm also not aware of it having a particular label.

Edit: sorry other questions. Type of software is desktop application, web applications, browser extensions, game modifications. And for why these particular paradigms were chosen, they were chosen because a customer/user wants to be happy and doesn't care about what paradigm is used, only the result. As such, the paradigm essentially follows some humans' whims, which mostly doesn't make sense and definitely is nothing "formal" at all.

Hi guys thank you so much for participating in my survey! I understand that some of you may not be familiar with the specific SDLC models used in your past projects. To help clarify, here is a list of common SDLC models that may have been used in your projects:

1. Prototyping Model: Quickly builds a basic version (prototype) of the software, gets feedback from users, and improves it through several iterations. It's helpful when requirements are unclear.

2. Spiral Model: Combines planning, risk analysis, and iterative development, revisiting each stage multiple times. It’s great for complex projects where risk management is key.

3. Fourth Generation Techniques (4GT): Uses tools that automatically generate code, speeding up development but still requiring testing and design. It's useful for small projects or prototypes.

4. Waterfall Model: A sequential process where each step (e.g., design, coding, testing) is completed before moving to the next. It works well for projects with clear, unchanging requirements.

5. Agile Model: Uses short development cycles (sprints) to create small, working parts of the software and allows frequent feedback from users. It’s flexible and works well when requirements change.

6. Scrum Model: A type of Agile, Scrum breaks the project into small, manageable tasks and focuses on completing them in short, time-boxed periods called sprints. Teams hold daily meetings to discuss progress and adjust plans. It’s great for projects where the team needs flexibility and constant communication.

7. V-Shaped Model: Like Waterfall but with a focus on testing. Each development phase is followed by a corresponding testing phase to ensure quality.

8. Incremental Model: Breaks the system into smaller parts (increments) that are developed and tested one by one, delivering functional parts early. It allows flexibility in adding features later.

9. RAD (Rapid Application Development): Focuses on quickly building prototypes and gathering user feedback to refine the system. It’s fast and flexible, making it great for projects with changing needs.

10. Feature Driven Development (FDD): Develops software based on client-valued features, with each feature being developed in small cycles. It’s effective for medium-sized projects.

11. Big Bang Model: Starts development with little planning and no defined steps, often used for smaller projects with minimal requirements. Changes are made as needed, but it’s unpredictable.

I’m involved scientific programming tasks (climate models) and we are largely using a mix of prototyping, feature-driven, and big bang models. It’s a result of the requirements for our work. Important is, that our “user base” is extremely small and in the beginning of a project mostly ourselves. The required features are given by the scientific questions and timelines dictated by project timelines from soft funding. Iterations are thus mostly more like “that didn’t quite work, I need another method” kind of arguments. Hence, the implementation of modular and fast evolving design is important and often we try to build our software such that fast development can be done on individual models.
Sometimes theres an idea on how to solve a problem more efficiently or with better performance. And then it’s all about coming up with any proof of concept.

Finally, there is not really anything like a management in our line of work. The professor is usually satisfied if the results work out and papers go out quickly. The rest ist largely up to the group of devs.