Hi everyone! I’m a student currently working on a research activity for our Software Engineering class, and I’d really appreciate your insights. 😊
I’m looking to gather input from software developers, project managers, or engineers about the Software Development Life Cycle (SDLC) paradigms you’ve used in your past or current projects.
If you have a few minutes to spare, I’d love to hear your answers to these quick questions:
-
What type of software did you develop? (e.g., mobile app, enterprise system, game, etc.)
-
Which software development paradigm did your team follow? (eg. Prototyping Model, Spiral Model, Fourth Generation Techniques (4GT), Waterfall Model Agile Model, V-Shaped Model, Incremental Model, RAD (Rapid Application Development), Feature Driven Development (FDD), Big Bang Model, Scrum, etc)
-
Why did you choose that particular paradigm? (e.g., client requirement, team familiarity, project scale, etc.)
Your input will be used for academic purposes only, and it would really help me complete this task with real-world insights. Thank you so much in advance!
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.
Yeah this. Every company I’ve worked in does 2 week sprints with a kanban to organise tasks but beyond that it’s pretty much normal project management; no faddy named models or anything.
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)
Damn finally someone got into the management position and made positive changes instead of just drinking the company cool aid and becoming a part of the problem. I was very frustrated at my last job where they would pretend to half heartedly follow some Scrum / Kanban process and pretend we are doing proper project design, and task estimation when everyone was just checked out and you as a developer are just expected to figure things out on your own and if there’s any delays in the project because the stakeholders changed requirements or other external factors they won’t adjust the time line and blame the dev for the delays if those deadlines aren’t met. All this focus on the “process”, the meetings the pointless RTO, but not one person was interested in getting shit done. No wonder the company had to resort to layoffs. Hopefully at my next job I’ll find a team that’s better managed.
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.
Thanks for sharing your experience! It sounds like the approach you’ve followed is quite flexible and adapted to each project’s needs. It definitely seems more like a mix of Agile and a bit of improvisation based on what the project manager or client prioritizes. I appreciate your insight!
Oh and as for reasoning why, another few points, all projects I’ve been in just kept being worked on and had constantly changing requirements. There was no real need to plan very much except maybe some rough estimations, that were allowed to be wrong.
There were like some very rough aspects of scrum in professional development, but only in the sense that we’d talk about what we’d like to do in the next sprint, we didn’t do multiple plannings or estimations or cared about our velocity or did retrospectives often, and even the sprints were adjusted to last longer or shorter based on what we’re going to do, there were a couple of roles people should have missing, and idk what. In the end, the resulting system was just something in the direction of agile/kanban, work just came in, and was handled based on some prioritizing by someone.
My personal projects could be really close to waterfall as well, I thought about a problem, made a rough plan on how to solve it, then just kept solving until I was done. Open source projects, no one organized anything, everyone just works on whatever they like.
Basically, you’re the expert in software development paradigms, I’m just a developer that works on problems with code until solved, either given to me by someone or myself. The only ones who care about the paradigm are the business guys who wanna plan some shit.
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.
How do you find such roles, coming from corporate roles this feels like it would be better for my mental health and WLB, plus your work contributes to scientific progress which feels better than just making rich people richer.
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:
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
V-Shaped Model: Like Waterfall but with a focus on testing. Each development phase is followed by a corresponding testing phase to ensure quality.
-
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.
-
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.
-
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.
-
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.
Where would “having two weekly meetups with everyone and talk about what is done and to do” fit?
-