Welcome, Guest. Please login or register.

Pages: [1]
Print
Author Topic: Leadership / the future of the programming department  (Read 7543 times)
zenbitz
Community member

Posts: 1164



View Profile
« on: July 22, 2009, 05:38:24 PM »

So you guys have one of the most interesting departments.    On the one hand, you have, by a significant margin, the most volunteers and contributors.  On the other hand, we have basically gone through 2 programming leaders in 4 months.  

Maximinimus is not "gone" but if any of you are parents you know how that first YEAR is.  Let alone the next 17.    He could be back in a week, or a month, or a year, or never.    It's not like he gets a pay check.

So one of you is going to have to step up.   And you have a doubly difficult job because if Max. comes back there will (probably) be some conflict (depending how long it might be).  Heck, if Saint Icelus comes back, there might be some tension....

I would really like to step in and do some managing for you (in RL I manage a small group of programmers) but my hands are pretty full with 2 _other_ departments and I haven't even gotten around to getting the old code running (not since Rio)

It's your project.  You are the ones doing the coding.  Someone volunteer to organize it, someone else back them up.  Toes might get stepped on.  Egos might get bruised.  Luckily, it's a volunteer project, so you don't have to come back the next day, hat in hand, because you have to feed your kids and pay your mortgage.

Treasure that freedom.  And make something great.

EDIT: title adjusted by barra.
« Last Edit: July 25, 2009, 09:02:26 PM by mvBarracuda » Logged

We are not denying them an ending...
We are denying them a DISNEY ending - Icelus
mvBarracuda
Admin
Community member

Posts: 1308



View Profile Email
« Reply #1 on: July 25, 2009, 09:12:18 PM »

As already mentioned in the other meta thread in the general subboard: I want to join the the discussion and would like to get your feedback on the topic.

Right now I can see the following problems ahead of us:
- Maximinus takes a baby break from PARPG and will be busy with other things for a couple of weeks if not even months
- Tie is switching jobs and has to do some freelance work to pay his bills; that means less / prolly no time for PARPG
- There are a bunch of new interested programmers around (kaydeth, jasontiller, b0rland) who might be eager to get involved but there is little guidance at this point due the tricky situation

As said in the other thread: I'm a bit overstrained with the situation right now but I'm sure that we can sort it out together. Staff changes are always tricky but the new situation might a good chance to introduce some changes that some of you might have lobbied for recently.

There have been ongoing discussions about the quality of the code in place and the need for more design before implementation. I'm no programmer and that's why I can only provide a common sense suggestion, hoping that you provide feedback if that's an actually reasonable approach. I guess we have to evaluate the current code in place to find out what is fine and can stay as it is, what needs to be refactored and what might need to be completely ripped out due broken design.

That thread is meant as a starting point. It's meant for the hopefully still involved established programmers bretzel, meggie and tZee as well as the new interested ones. It would be especially interesting how familiar the new programmers are with our codebase. Furthermore it's important to me to get your feedback what changes need to be introduced to cope with the new situation and how we could continue. Feedback please!
Logged
b0rland
Community member

Posts: 105



View Profile Email
« Reply #2 on: July 26, 2009, 01:46:26 AM »

First of all, I must admit that my code knowledge is still close to zero. I've been carried away by your wiki, guys. Very interesting reading (which owes a lot to Zenbitz's articles; way to go, man).
That means that right now I'm writing from general experience with various projects rather then actual knowledge of PARPG code.

The project needs the lead developer in the long run, but, as I understand, Maximinus hasn't been away for too long yet and there's still a (tiny) chance he comes back soon. Anyway, finding a new lead isn't something that'll magically happen the moment we decide to start looking. Especially since noone volunteered yet. So we must face the fact that the project will continue lacking a lead developer for some more time.

Meanwhile the things that seem to be the most pressing are:
1) Accommodating new developers. The main rule is -- for a person to REALLY learn the code, understand it and live it, she needs to work with it for some time. Perform some tasks. So we need a list of simple tasks that help newcomers figure out how things work. These can be low-priority mundane things nobody really got to doing. Hell, you can make things up even if nobody needs them, or take something that's planned for version 15.0. Add them to Trac and mark them somehow (e.g. [newbie]).

2) The code needs review, redesign, refactoring. Yes, it's a good thing for code uniformity when some single person reviews and maintains all the code and he is all-powerful and his word is the law. But I never saw that happening in real life Smiley. In our current situation, I think our best bet is have the code reviewed by community. And here I mean 80% oldtimers, 15% newcomers, 5% just about everyone willing to speak his mind. We can do it one part at a time. Give each part one week by default (but that can be quite flexible, and they can overlap too), announce the review and have everyone willing to devote their time to review that part, post their comments and potentially engage in future discussion. In case the arguments emerge (and they will), we can vote (with certain bias in favour of oldtimers since they have a prior experience). Specifics can be decided later, the main idea is to have at least one organized iteration of code review to fix the ugliest pieces and also fix the general design early.

3) The new code needs review even more. Especially the code by newcomers. This essentially means that all the oldtimers get a 'reviewer' status and are encouraged to spend a part of their time reviewing new patches as quickly as it is possible. This might sound irritating, but I doubt it will be: I don't really think you'll be overwhelmed by code submissions.

There's no reason why 1) should wait for 2). There's no reason for any of them to wait for Maximinus, as long as oldtimers are willing to engage in them. These are not fulltime activities. An hour a week is probably enough for all the three for a person who knows the system.

4) There seem to be not many real tasks in Trac. I'm talking about the big development tasks for seasoned developers. tZee posted some, which is great. But are they really all that's necessary for the Techdemo 1 from programming standpoint? Maybe we should have the tasks that aren't well defined yet in Trac too? To have some sort of a development roadmap, to show the experienced developers what needs to be thought about and worked on.

So, are there people from the experienced parpg programmers who would agree to help with some of the above?
« Last Edit: July 26, 2009, 02:10:36 AM by b0rland » Logged
Kaydeth
Community member

Posts: 185



View Profile Email
« Reply #3 on: July 26, 2009, 02:21:45 AM »

I'd be more than happy to contribute to some code reviews.  If some of the veterans could pick out pieces to go over than we could take a shot at it.

Seems like we need to refocus on what's important for right now. I dug up some of the wiki roadmaps. Perhaps discussing the goals listed might help us.

This first one is from the main road map section for Milestone 1 (I beleive Milestone 0 has been officially reached). I put some red comments inline:

Programming

    * Frame an initial core model.  This seems very vague. Could anyone expand on this? Has it been completed?
    * Begin work on support tools for writers.  These things basically haven't been started right?
          o Story engine.   Does this refer to the Story Engine Proposal or a just in general a mechanism for story events
          o Story playground.
          o Consider the spec needed for a story editor.
          o Consider the spec needed for a map editor.
    * Begin compiling required FIFE modifications.  Again this is very vague to me? Any more details?
    * Begin compiling list of required GUI elements. More details? GUI elements for what functionality?
    * Refactor and analyse Rio code.    Do we currently have parts of the code that we are interested in?



This second road map came form the Programming section of the Wiki and seems to have bee put together by Maximus

    *  Enable saving and loading of maps     Does this mean save the game? what does save the map mean?
    * Implement a simple console (low priority, useful for debugging)       
    * Add another map and enable the player to move between then  Is this actually needed for milestone 1?
    * Link the inventory with the game objects, so that the inventory really works   
    * Implement simple dialog trees with the NPC    Not started yet?
    * Add a front end ('start a new game', 'load' etc...)   
    * Allow user to add run with arguments, i.e. ./run.py --resolution 800:600


It would be good if we can figure out if all of these goals still apply and which ones are complete, under construction, and not started.  Then possibly we can translate then into Trac tickets or at least update the Wiki so we are all on the same page.
Logged
meinmartini
Community member

Posts: 95



View Profile Email
« Reply #4 on: July 26, 2009, 03:42:34 AM »

Even from a team standpoint, it'd be a good idea to list what you'd like to learn by week's end. That way you give yourself a set of goals and a chance to fulfill them. One thing leads to another. Unless everybody's completely lax about what needs to be done, even getting some minor task completed gives you a greater idea of what to work on next, and so forth.
Logged

Let's fight some ballerinas.
Bretzel13
Community member

Posts: 73



View Profile Email
« Reply #5 on: July 26, 2009, 07:23:07 AM »

    * Begin work on support tools for writers.  These things basically haven't been started right?

I have started on a tool for writers to develop the story. Right now it is just a shell as we have had no consensus on what to do for the language.

As for leading the programmers, I have had zero experience managing programmers or people in general. I could definitely help direct the programming so the right things get done in the right ways, but I would have to lean on you for some things barra.
Logged
mvBarracuda
Admin
Community member

Posts: 1308



View Profile Email
« Reply #6 on: July 27, 2009, 04:12:55 PM »

My intentation might appear a bit blurry when I replied to zenbitz' thread instead of creating a new one. While the topic is quite similar and I therefore rather replied to his thread than to create a new one, our intentation might be a bit different.

I didn't want to propose to just "select" a new lead programmer and let him set things in stone. I'm more interested in an open and honest discussion about the issues that we currently have to cope with and how we could resolve them together. Furthermore it should NOT serve as a name calling platform, finding scapegoats.

Right now it seems that our roadmap is quite blurry. My non-programmer impression is that without a more solid roadmap it will be pretty much impossible to come up with actual tasks that you (the programmers) can work on. These tasks should be moved to Trac so that newcomers can also get an overview what's already done, which tasks are taken and being worked on and which ones are still left for taking. I'm hoping that using the ticket tracker for this purpose will also make us less dependent on single developers. Developers have a real life and might need to take a week off or two and that's perfectly reasonable. I'm just lobbying for a project structure that makes it easier to cope with these kind of aspects of free time development.

It would be great to hear the feedback of the others on the topic. We can't fix anything if we don't know what's broken. I'm just like an external viewer that watches the situation and has the impression that there are some problems, but I'm not 100% sure what they are and which the most important ones are. Therefore I rely on your feedback, I can't do anything to resolve that on my own.
« Last Edit: July 27, 2009, 04:14:54 PM by mvBarracuda » Logged
Kaydeth
Community member

Posts: 185



View Profile Email
« Reply #7 on: July 27, 2009, 04:58:43 PM »

I agree from a new comers perspective that the programming roadmap is very blurry. I strongly believe that we need to clean up the roadmaps. Here is what I would like to see done:

Barracuda I think you should take ownership of the higher level roadmap. This roadmap should be a very high level desciptions(think user level functional descriptions) of what our department is working towards as well as a complete list of cross department goals (by example I mean something like a story editor, things that other departments would benefit from or are waiting for). Also I think you should remove things like "FIFE modifications" and "Analyze Rio Code". They are very detailed and should be part of our department specific roadmap. If you really want to represent the effort try something more encompassing like "evaluate existing demos".

As for the department specific roadmap we really need to make sure we repesent more detailed goals for everything listed in the higher level roadmap. At the moment the roadmaps don't match up very well. We should also try to cut down on any extras that are not represented in the high level roadmap. We could add a "wishlist" section for these goals perhaps.

In the mean time it would help a lot to get any and all information on the status of things on the roadmap right now. Thank you Bretzel for your information on what you are working on.

So for now I'll try and work with Barracuda and Maximus to refine the higher level roadmap.
Logged
tZee
Community member

Posts: 190


View Profile Email
« Reply #8 on: July 28, 2009, 12:05:13 AM »

Here's a piece of history:

- Maximinus was for a long time the only programmer, thus becoming the "lead programmer"
- Meggie joined the project, having little to none experience in designing/object oriented programming she sought guidance (She declared that in her very first posting I believe: wanting to learn c++ programming. And many times after as well, wanting to learn object oriented programming etc.)
- I joined the project and had to learn that Maximinus didn't think highly of planning, design and object orientation. Thus I started drafting some design diagrams and proposed to get some more thinking into the development
- This resulted in lots of disputes over little matters and philosophies in general, which I found very tiring
- Tie was animated to contribute again with the new planning. Before his "retirement" a few months ago he complained about the lack of planning

Ok, skipping all the ranting that I was about to write again:

I don't want a lead position, it's too much effort and too unnerving for me. (I'd rather code away, but for that I have to agree with the direction and the planning. Cheesy)
I am up for an environment of open discussion - with people who have experience in the field of game programming (or at least with object oriented collaborative programming porjects Cheesy). I set some hope in the new people here. Smiley I do have experience in designing and object oriented programming, but not as much as I wish I had. So far there was only Tie who would contribute to my suggestions, to criticize them or to improve them. I hope in the future there is more such exchange going on.
Also I am not really the person who motivates others... I rather need some motivation sometimes myself. Smiley

To the tasks I created: They were the ones I could think of at that point. I proposed that everyone else adds more if they could think of any, but as it appeared I was the only one at that time doing the planning. Again: I have some expectations of you new guys! Smiley

I agree with Kaydeth: We need to get the roadmap down and the clean up the code.. It's still such a horrible mess :/
« Last Edit: July 28, 2009, 12:13:26 AM by tZee » Logged

meggie
Community member

Posts: 30

Python programming looking for some C++ experience

un1meg
View Profile
« Reply #9 on: August 03, 2009, 03:56:19 PM »

Quote
Meggie joined the project, having little to none experience in designing/object oriented programming she sought guidance (She declared that in her very first posting I believe: wanting to learn c++ programming. And many times after as well, wanting to learn object oriented programming etc.)

tZee, I've actually said repeatedly that I've been doing OOP the entire time I've been programming. I just don't know C++ syntax very well (as opposed to straight C syntax).

I haven't been working on PARPG recently because I've been on vacation, but also because the code is really messy right now, and we still don't really seem to have a plan for restructuring. Alas, I have no leadership abilities to speak of.
Logged

-Meggie
Kaydeth
Community member

Posts: 185



View Profile Email
« Reply #10 on: August 03, 2009, 07:34:20 PM »

I haven't been working on PARPG recently because I've been on vacation, but also because the code is really messy right now, and we still don't really seem to have a plan for restructuring. Alas, I have no leadership abilities to speak of.

Hiya meggie. What do you think needs restructuring?

For now we're trying to focus on Milestone 1 which we've re-defined here: http://wiki.parpg.net/Programming_Roadmap

Unfortunately it just seems like it's tZee and I for the moment. We would love to get some help from you also.
Logged
Bretzel13
Community member

Posts: 73



View Profile Email
« Reply #11 on: August 04, 2009, 05:23:12 AM »

Hiya meggie. What do you think needs restructuring?

I've been busy on an editor for the writers until we get something cleared up on how to go about the development. The editor is now in SVN.

As for what needs restructuring? tZee has done a lot in restructuring objects and the way they are handled. I think the biggest mess specifically is world.py. If we could tackle that, I think it would be fairly easy to restructure the rest. (And a lot of restructuing would be done in other files while working on world.py to keep the game working)
Logged
Kaydeth
Community member

Posts: 185



View Profile Email
« Reply #12 on: August 04, 2009, 03:57:32 PM »

Sounds great Betzel. I'll be sure to check out what that editor can do Smiley.

As I hope you can probably tell I've been trying to organize and focus the development effort but refactoring and restructuring code is not something I can dive into as I'm so new to the project. I'm not familiar enough with the code and I'm also not familiar enough with OO design to have a clue on how to improve things. So in general I would ask that all the developers try to create specific refactoring task (i.e. redesign "this" class, or redo interface between class 1 and class 2). A good example is this task: http://parpg-trac.cvsdude.com/parpg/ticket/68 although the title could use a little work Smiley. Try to be as specific as possible and then we'll add those tasks to the appropriate milestones.

Another option is to begin a forum discussion about the idea and/or problem and once enough information is collected I could create the task myself.
Logged
Pages: [1]
Print
Jump to: