It’s worth reading through the first four parts of this series if you haven’t already: “Introduction“, “Hiring“, “Orientation“, and “Training“.
Once we’ve finished subjecting our new hires to a week (maybe two in future) of classroom training, we turn them loose on an internal project. The core goals of this exercise are:
- Familiarize new hires with our process and all the steps that go into a project.
- Apply concepts learned during formal training, and continue their technical growth.
- Begin developing their competency in critical secondary skills including estimation, time & project management, project planning, user experience (UX), leveraging existing resources, effective communication, QA and issue resolution.
- Develop skills with tools including development tools, SVN, and Basecamp.
- Start them thinking about value and business considerations for projects.
- Force them to respond to feedback and changes in an agile, responsible manner.
The trainees are informed about this project on their first day at work, and reminded of it throughout their first week so that they can brainstorm ideas in advance. They are also encouraged to run their ideas past people to get feedback. Over the course of the second week they then develop a full project plan, which is maintained and organized in Basecamp.
At the start of this phase (usually the first day of their second week) the trainees are asked to solidify their concept(s) for their internal project, and prepare whatever materials they deem necessary to present it.
The only requirements for the project is that it fit in a 2-4 week timeline, and that it provide value to the company. This value can come in a number of forms; it could be useful, have market potential, have promotional value, contribute to the knowledge of the company, or it could just advance their training in a significant way.
At the end of the first day of this phase, they present their concept(s) to the senior staff, and are presented with feedback as to its viability, value, and implementation. They then revise their concept based on that feedback.
Next, the trainee develops wireframes, defines user flows, and identifies any data requirements for the project. Again, this is presented to available senior staff and revised based on feedback. In particular, we focus on the appropriateness of the user experience, and the completeness of the wireframes, flows, and data requirements to ensure the trainee has a good understanding of the full scope of their project.
The trainee then moves into doing some high-level architecture. They prepare a CRC outline (classes, responsibilities and collaborators), and an I/O spec (input / output for a web or local service). Once again, this is presented and revised.
With the architecture approved, they write up a project plan that includes a timeline, with milestones and micro-deadlines (ie. goals for each day or two).
Once all of this is complete (generally on the Friday of that week), they present their complete project plan (wireframes, architecture, I/O, timelines, etc) to the entire team for feedback and criticism. This lets them receive and filter a range of input, as well as letting them see the more experienced members of the team disagree and debate different ideas.
With their plan complete, they are ready to move on to production, which is the focus of the next article.
Do you have them create UML before production? Or in general does your company often produce UML diagrams before production? If so, what program do you use to create them? It seems like gModeler is a diseased project and I wasn’t sure if you’ve found a good alternative.
Could we see examples of previous trainee projects?
I don’t know what “wireframes” are, and I would love to see how you visualize user flows, CRCs and how you document data requirements.
Is it very formal with specific formats / templates, or are we talking MS Paint and a textfile?
Hi Grant,
I’m curious to know if the process which the trainees need to go through to develop a piece of software is the same the production team uses, if so it seems to me really heavily documented (wireframes, architecture, I/O, timelines, etc).
I understand that some kind of documentation is necessary like wireframes and user flow ,even though IMO the user flow should be created by the Designer/UI guys, developers have a tendency to create “developer user flows” they don’t really think like the average user (they know too much about the invisible layers of the application), and from experience an Architecture document can work really well on paper but then when implemented it shows up some flaws that will then force the developer to take a different approach , the document then is out of date and needs updating which can be time consuming. In the past I read architecture documents that had nothing to do with the real implementation of the application.
Btw I can see the value in asking trainees to produce those documents because it’s a way to see how they solve problems and it can help in discussion meetings.
So back to my first question, could you explain how a project is developed from start to end in gskinner.com? (if you are happy to share the info)
cheers
Vizio
hmmmmm… really interesting, but yeap “wireframes” sounds a bit abstract, I really would like to take a look on this training model your dealing with (deeply). Thanks for sharing, I think it really worth to share all this with the DEV community, I’m actually thinking in translate it all properly to Portuguese and Spanish, there are many people out there interested on it. Cheers!
thanks for the insight, every bit helps.
Vizio ++
It all sounds so waterfall… Why not more agile?
Hi Christian,
This isn’t about the waterfall – agile dispute, I am not advocating one or the other. Each team should adopt the development process they are more comfortable with.
We all know that gskinner is quite a successful company so evidently they are doing stuff in the right way (at least for them) so I wanted just an overview on how they approach projects.
Vizio
I have been working on a project recently that uses Scaleform GFX, of which you did the components for… Seriously dude, you should not be advising ANYONE on how to be a good programmer. Seem to remember those horrible components you made for Adobe but those things were nice compared to the gfx ones. Never seen such convoluted crap before.
If anything they are a good example of what not to do in coding and why it is best to be as explicit as possible in architecture and coding. Just getting the things to work in any sort of normal usage ends up in wasted time messing about with them.
Please retire before you ever make a mistake like that again that affects the rest of us coding in AS.
alan – wow, that was harsh! I’m sorry you’re not a fan of CLIK – in general the feedback has been very good. The architecture is somewhat convoluted – this was necessitated by the specific requirements that were dictated by the use cases, skinning requirements, and limitations we faced trying to make them work well in GFX and adequately in the Flash player. We spent a lot of time trying to make them as easy as possible to understand and extend, but a lot of compromises had to be made.
Likewise, I have plenty of reservations about the CS3 components – they were one of our first major AS3 projects (heck, they were probably *the* first major AS3 project), and had extremely tight time & budget constraints. If I could do them again today, they’d be a lot different (and I’d insist on a lot more time to get them right), but I’m proud of the work we did with what we had.
Component development is probably one of the most challenging tasks in programming. You are attempting to please a plethora of diverse interests operating at very different skill levels, create an understandable / extensible architecture, facilitate multiple models for skinning, and optimize for performance. In our case we were also working with beta environments and/or brand new languages, and trying to integrate with an IDE that, to be frank, has a really poorly developed component model.
Until you’ve developed a complete set of commercial components, within a strict timeline and budget, and incorporating feedback and requirements from multiple major stakeholders, it may behoove you to tone down the rudeness of your posts. I’ve built 5 component sets in the past decade. Every one of them has things I’m proud of, and elements that aren’t done as well as I’d like (and a few parts that are embarassing to revisit) – whether due to time restraints, necessary (but perhaps non-obvious) compromises, or just plain ignorance.
I understand your frustrations, but rather than venting them on my blog, why not write up a constructive summary of what you’d like to see improved and send it to Scaleform or me? We are actively interested in improving how the components are built and used.
Regards,
Grant.
Grant, you are right, it was entirely inappropriate and rude of me to vent on your blog. It is easy to be judgmental after the fact. Frankly I was completely surprised you did not just remove the post but chose to respond to it. It was a Troll statement and I am pretty embarrassed I made it. Please accept my apology.
alan –
I appreciate your apology. It shows class, especially on the internet where it’s so easy to just walk away.
The offer to submit constructive feedback on CLIK is genuine. Good input is always tremendously valuable, and Scaleform is committed to making the components better.
Hi Grant, I’m skeptical about trainees creating an application that is useful to the company (unless it advances their own training in some way, as you said). It seems like a trainee would be able to address only the low-hanging fruit and there will be less and less of that as the company continues to mature. When I hired into my current position there weren’t any small projects to do. I love the idea that a new person could create something right away that they can take ownership of and that benefits the organization, I’m just not sure it’s sustainable. Perhaps the size of the company makes a difference. The company I work for is pretty large.
By the way, I love the new site.
Hi Don – the idea isn’t so much that the new hires need to create something that is genuinely useful to the company (a tough task for a junior developer with only 3 weeks to work with). It’s more about them working on the project with their value proposition as a focus for decision making. Understanding the value a project delivers to both the client and the end users, and how that drives virtually every decision in design, architecture, and development is the critical lesson. If we actually get something useful at the end, that’s a big bonus!
Also, thanks for the unintentional reminder that I should finish up this series – I almost forgot over the holidays.