Software development methodology

News & General Discussion
1

Purely curious, what methodologies (Agile or otherwise) do you use? What has been your experience?

My day job is a highly responsive custom code company that is trying to become a product company, and we’re moving from a very chaotic waterfall model to scrum over the past 6-10 months. We’re seeing some benefits but management has to make some tough decisions to really support it. Culture change takes time too. I’d have to say that Scrum master training doesn’t prepare you for implementing it and working with managers that are terrified of letting go of control.

2

We use agile/scrum at my day job. but as for game dev, agile or even using a style of lean development. I haven’t seen waterfall work now a days. Management always screws waterfall up. going full scrum can and will be extremely hard for management… and after you get your daily meeting/priority meetings/estimation meetings done at a good pace you will see how beneficial for the entire company it is. either way its a huge cultural switch from waterfall.

I don’t see managers losing control in scrum though, that doesn’t make sense? they set the priorities, they are fully in control of what gets done and when it gets done and when it goes to production. if anything they are more in control. I mean waterfall promotes large periods of bad decisions that will need to get fixed at the end of the waterfall sprint which will require developers to sit under the desk and sleep their 2 hours to get their work done in time.

3

I think it really depends on the team. Our current team uses a modified agile/scrum with pods (2 week sprints - pod scrums and then dailies). It works well. My previous team used a very light version of scrum (one week sprints with all-hands standups every morn) that worked well for that team. Other projects have been variants.

4

Hmmm… while working on a big data hypertree program in java, what worked for us was…

1)What needs to be done?
2)How do we do that?
3)How do we do that (#2)?
4)repeat steps 2&3 until the process is just basic steps

When you’ve got all of the components you need laid out end to end, start making them. I don’t know if there’s a name for it, but this strategy that I learned in high school was taught to us writing class & method prototypes until the entire program was blueprinted and just needed to be implemented.

[public/private] [static/non-static] [return type] [method name] ( [parameters] );
public int getNumberOfCategories(String pattern);

Stuff like that, in a big drawing. Drawn inside components (boxes) connected to the components (more boxes) that needed them and so on. It worked in high school, it worked on a few programming jobs and it’s worked out well in college so far.

2 Likes
5

I really like your idea Tomnnn it sounds stupidly easy.

6

Thanks, it is :smile: As someone who’s been in the field for 6 years, the look on people’s faces never ceases to amuse me when I propose this. The most technically advanced it gets is all of us sharing & editing a photo over google, which became easier with google drive.

It also makes it easy for the business people of your group to explain how the program works to a client. Also, it enforces modular design, so any components in the design can be modified, cut or swapped out for a similar one without redesigning everything. Is a feature going to be completely cut out? Just sever the lines in it’s connection to other components that are being kept in, and you’ll see the remaining connections to that feature are also being cut.

Would anyone like to see an example? hehe :smile:

7

Yes there is a name. It is called good ole fashioned common sense. Which probably explains the shocked look on people’s faces. :wink: lol

Actually, this is basically Divide & Conquer and is the same thing I do. Continually breaking the task down into a list of smaller tasks. Not only useful for programming but any other project as well. And in fact, is what I use to tackle any project or other goal in my life. Although with goals I do it backwards. Starting with the end result and then “what happened right before this?” “What happened right before that?” Do that all the way back to where you are now. Flip it around and you have a plan for how to get from here to there reaching your goal. But anyway, yeah let’s stick to game stuff. :wink:

8

My view is be flexible in your approach, pick something that the team are happy with then adjust it as the situation demands. My main problem with SCRUM is that it tends to lead to zealots who will not deviate from the doctrine. The idea of a retrospective is great, but it should be applicable to your process as much as your feature set.

In the day job our current product development team (http://www.limepoint.com/environmint) uses an iterative approach which is closest to Kanban. The biggest issue here is maintaining and managing velocity when you have a wide range of experience on the team, but I find it is great at the moment where all of our devs have 10+ years experience.

In most of our large project work we use a waterfall framework with individual streams delivering using an iterative approach much like a simplified SCRUM. The overfall waterfall framework is all but mandatory for large fixed price contracts in the enterprise space where payments are tied to contracted milestones and requirements. On the negative it can be tricky managing an agile feature set vs static requirements (with a typically slow and expensive CR process).

1 Like
9

I’m not sure that @Tomnnn 's approach is really a methodology, its pretty much a mandatory step in all software development to divide the work in to small chunks (be it recorded as part of a project plan, or a story, or simply by the individual developer working out what they need to do).

A methodology needs to give you a framework for defining how the work gets done, not just define what work needs to be done.

10

That kind of thinking seems to be slowing everyone down when I see it try to be implemented :wink:

Once you lay out the steps in getting it done… the groups I work in… get it done. There is no choice in how, they just do. If you finish a method required by another method and you’re still on the clock, make the next method. You already know what needs to be done from the process of breaking things down completely.

I’m using it now on game stuff :smile:

11

Breaking down to the method level for a large project would be months of work, and the reality is you don’t know what you need at the start of the project, avoiding such large upfront commitments was one of the main drivers for agile. Even waterfall would rarely go anywhere near the method level during inception phase. Generally method level decisions are left to individual developers or small teams (unless its an interface needed by other teams/systems/components).

Obviously you don’t need to go over the top with methodology if you have a few people working on a simple project, but I think you would be very surprised at how much better you get at estimation and delivery if you put a little more effort in to the process by which you deliver.

EDIT: Thinking about it I expect you really are just using waterfall. You have some kind of requirement you need to deliver, you have a (very detailed) design phase up front to determine what you need to build, you build it, then (presumably) you test it, then you hand it over. That’s waterfall.

12

If I didn’t run into issues doing so trying to build a database of tweets to analyze to find patterns to suggest possible crimes going on in a few days, then I don’t think I’m ever going to exceed a week in my life using such a method. It’s not like you need to literally break something down into it’s every single method needed, you just need to go until you know how to implement the required component(s).

I believe I can improve my [financial] estimate if I use some kind of method like that. I’ll just assume it’s some kind of programmer secret to waste time and get paid more, and I’m obliviously trampling all over it.

If it works for you, great. But I wouldn’t do that to my clients & group mates :stuck_out_tongue:

13

The project you describe is just the kind of thing that is well suited to a simple design approach. From a behavioural/interface perspective the system is likely quite simple (although I assume there is significant complexity in the algorithm and performance aspects of the problem, I’m certainly not trying to downplay your achievement).

If we assume your team and process is 10 times better than the avergage your twitter project is still only approximately a 30 day project. Thats tiny. Of course theres not a lot of detailed methodology required.

But you need some perspective, here’s a snapshot of the latest tender I’m working on. 250 pages of RFP documentation and a spreadsheet detailing ~1800 requirements. Integration with ~50 third party systems, as well as ~10 internal systems (one of the extenernal interfaces has over 200 message types which need to be handled). To think that the design for that would take less than week is crazy, we have had 4 people working full time for two weeks just on the tender response.

But regardless of any of this my original point still holds: You haven’t defined a methodology, you have defined just a little slice of your process (how you do detailed design and how this relates to a task list).

You haven’t defined how you allocate those tasks. Can anyone take any task or is there some direction or priority.

You haven’t defined how you actually decide what you design. What happens before detailed design, presumably you need some kind of specification, requirements or at least workshops with the customers.

You haven’t mentioned how you test (what do you test, when do you test, how do you test) nor how you handle defects revealed by this testing process.

You haven’t described how you measure progress and performance, is the only metric you have number of methods completed? Do you assume all methods are equally weighted and if not how can you say you are on track?

What happens if something is blocked (e.g. because a function someone else is working on is incomplete). Do you have a way to report that, and move on to another method?

How does a customer accept your product? What do you do if they don’t?

How do you deal with designs that need to change?

You must have some way of handling most if not all of the above, and when you describe all of that then you have described a methodology.

14

JohnnyA just described exactly what it was like working for the public service. Now that I work alone I pretty much do what Tomnnn does. Of course, the problem domains are completely different too.

15

Hah yeah its worse when the clients are public service, these guys are actually very progressive, a super lean JIT type company willing to push everything to the cloud and do some cool stuff which I’m not sure I’m allowed to talk about :slight_smile:

Working alone is a bit different, in that case I don’t usually go beyond a few lists for phases, features, assets, etc. Although if something I big I might still use sprints and have a bit more of a formal process (allocating some time to reflect on how things are going can be beneficial even solo).

However the implication that methodology beyond detailed design is just a waste is going a bit too far for me. Anyone from a solo developer to a five man indie team to a AAA will benefit from at least thinking about how they deliver.

16

My final word on this, as I need to go to do some work:

Using an existing methodology is (to some extent) analogous to using an API. Its not that you can’t come up with your own, its just that an API tends to solve a common problem reasonably well for much less effort. You may need a little up front effort to pick the right API and you may need to adapt it to your needs but most of the time its going to be more efficient than rolling your own.

17

@JohnnyA
Yay, questions! Hopefully this can clarify whatever the process is. I’m not to sure myself beyond “get it done”.

Q: Can anyone take any task or is there some direction or priority.
A: Yes and no. Anyone can take any task, as long as people are all on different tasks. Because of the modular design enforced by the process, sample data based on use cases can be used to test functions before other components are finished.

Q: How do you decide what you design?
A: If the problem in need of solving can be described at all, then it can be laid out with this system as a series of components.

Q: Specifications, requirements, etc
A: If a client is coming to me with half an idea, I ask what it is they’re trying to do and show them a layout of their current idea. I make suggestions by adding other components to the diagram, both suggesting functionality for their project and partly instructing them on the meaning of the, as Mr. @GarBenjamin put it, common sense diagram.

Q: How do you test [a component]?
A: Sample input compared to expected output. Before the method is even described or developed, sometimes all a client can do is give me a handful of inputs and the expected outputs after the function has been run. The inputs and outputs will be fed into the component to make sure it is working correctly.

Q: How do you handle defects in the testing process?
A: The modular component design & unit testing lets us know immediately where the problem is. If the group is hand picked by me, then everyone is familiar with developing highly cohesive system. In that case, it is even easier to find where the bug is happening.

Q: How do you measure progress and performance?
A: Performance among the developers? The amount they can implement I suppose. Progress in the project? Whatever’s done. I’ll let the client know what’s being worked on and how important that is for significant feature x or y, and show them some working functions with sample data that suits their project.

Q: How do you know you are staying on track?
A: If every work session involves progress :wink:

Q: What if something is blocked because a dependency is still being worked on?
A: In modular component development, that is not an issue, ever.

Q: How does a customer accept your product?
A: They have access to the source code & a working setup of it. If they’re paying me to build the product, I’ll build and document the product so someone else can integrate it. If they’re paying me to build their working system, I’ll take the working project and get it running on their systems.

Q: What if the customer doesn’t accept the project?
A: The contract would ensure everyone involved gets paid, and then everyone has a nice day. I’m willing to make changes to the project, but if they arbitrarily decide they no longer wish to pursue the venture, they can pay us for the work done so far and cancel the contract.

Q: How do you deal with designs that change?
*A: I sever the connection in the diagram of the component being changed (which shows what components are no longer connected to the project), to show the client what’s going to be lost when the change is made. I then draw in the new component to show what functionalities are restored / changed or completely lost by the change. At this point, the client is well informed in how the diagram works, and will have an understanding and be able to make an informed decision when modifying the program.

Those are more reactions than set rules haha. Most of the important questions are answered implicitly by the process.

–edit

*A benefit to this layout is having non-programmers (like perhaps… the clients) make changes to the program and having full knowledge in what will become broken or lost when the change is made.

I have a feeling the NVidia optimus setup was made in such a way. One day, a non-programmer connected the discreet card to the integrated card instead of the display in the hardware document, and the room was awed by the unintended brilliance :wink:

1 Like