In May 2010, I conducted a workshop on 'Introduction to Profession Software Development' in Sir Padmapat Singhania University, Udaipur (SPSU). Previously I have conducted various introductory sessions for new joinees in Geometric Ltd (my previous employer). In all the projects that I worked on, usually 50% team members were 'freshers'. While working with these fresher/new joinees, I realized that even computer science students have no clue about 'professional software development'. Most of them have not even heard of 'version control' so there was no question of using any version control system.
Obviously when they join a software company, it is a 'culture shock'. Also when these students try to work on some short internships with the industry, they spend more time learning such tools/practices rather than development of their project. Hence industry mentors are not very happy with the output of such internship programs.
The objective of this five day workshop was to reduce the intensity of this culture shock and help students to with internships, last year projects and also prepare them to work on programs like 'Google Summer of Code'.
Participants were divided into teams 4-5 students each. A SPSU professor was assigned as 'mentor' to each team. The daily program was divided into
- class room sessions of about 2 hrs every morning,
- 15-20 min presentation about yesterdays work by the teams
- working a 'mini-project' during remaining time.
I conducted following sessions during the 5 day program along with reviewing the design/code. The team of SPSU professors worked with me to mentor the students, answer their queries, review the code/design etc.
Day 1 : Difference between amateur and professional software development. And the tools of professional software development (e.g. Version Control, Bugbase, Build systems etc).
Day 2 : Writing specification document
Day 3 : Key Principles of Software Design and how to write design document.
Day 4 : Principles of User Interface Design
Day 5 : Bad coding practices and how to avoid them.
The workshop was very interesting experience.
- Most of material I prepared before hand has to heavily modified based on interaction with students.
- As usual some student groups were not at all interested while some groups did fabulous job.
- The professors were serious about mentoring the students and took a keen interest in their teams work. However, many professor didn't have any experience of working in a industry and it showed.
- Many students had done a basic java course. But most of them did not have any idea on developing a GUI in Java. Same was true for students working on C# or C/C++.
- Some teams worked on Turbo C compiler. Obviously that experience with Turbo C and developing GUI with TurboC is not going to be very useful today.
The Program was organized by Industry Readiness Center (IRC) and Sir Padmapat Singhania University, Udaipur (SPSU) in collaboration with Poorvanchal Systems Pvt Ltd.
What do you think about such workshop ? Will they be useful to students and industry ? I am interested in hearing about your experiences.
2 comments:
Hello Nitin Sir,
I felt good to know about this seminar. I should call those students lucky :) - they got training from highly experienced trainer.
I will be surely interested in attending your seminars on design methodologies and any other similar courses if you plan for professionals.
No doubt, such a workshop will add a great value. It will of help to frshers as well as the project they join.
One observation regarding tools: Let's say a developer doesn't know about version control to start with. So when he joins the project he is given a dose of elaborate training on svn or whatever the tool is.
Now the problem is, the developer now knows svn (or x) very well, but he is still not aware why to use the version control system! Why it is a good practice to "commit early & commit often".
I'm putting your approach in the following way:
1. Tell the team working on mini project that they should be able to demostrte "working software" as & when they are asked. They should continue working on new features, but the program they demo must be stable, it's ok if it has less features.
2. Team will somehow manage to do that. Perhaps they will start taking daily or hourly backups, integrating it and experience the pains in doing that.
3. Now introduce them to svn. Introduce them ONLY those features of the tool that solves their problem.
This way they quickly understand that version control is like a "time machine", you can go back in time! It helps you to move from one CONSISTANT state to another. They also understand why it is important to "commit early & commit often".
This is analogous to RED->GREEN->REFACTOR
1. See something fails
2. Put a working solution, may be that is dirty.
3. Refactor the solution to make it clean, elegant, scalable. This is point where a "tool" is to be introduced.
It's TDD!
Post a Comment