How to implement a development process with college students

softwareengineering.stackexchange https://softwareengineering.stackexchange.com/questions/373934

Frage

At my first job as a software developer, my team used agile/scrum to manage our project workflow and it worked pretty good. I had some experienced mentors who set me on the right track - I owe them a great debt of gratitude. I worked there for a few years, then moved on to a new opportunity a couple months ago.

Fast forward to my current job. I work at a university under the direction of a professor. Since I’m at a university, nearly every programmer is a student (they're cheap and plentiful!) My boss has management experience, but not with software development, and the software team isn’t always on the forefront of my boss's mind. These conditions have created the perfect environment for creating some very poor quality software. Software projects seem to run a bit rogue, have no thought to design, and have employed some truly frightening practices. I know things could be better.

I want to implement a development process to help get everyone on track, increase the quality of code, and deploy more stable software. I'm just not sure where to start.

I am not looking, per say, for answers like "Use Scrum", "Set up a kanban board", or "Take a look at agile!" (although ideas are appreciated). More specifically, I'm hoping to gain insight into how to implement a development process for this work environment. Employees usually work between 1 to 2 years before moving on, are generally inexperienced, and daily standup meetings that include everyone are near impossible to schedule.

How does one foster quality, efficiency, and communication in such a workplace?

Update: After reading some of the answers and comments, I thought I'd provide some additional background.

I wouldn't consider myself a master at the art of software development, but I am experienced enough to recognize bad programming when I see it. I can determine if a developer is talented or not after spending just a minute or two working with them. I'm comfortable with my own abilities to find a way to solve a problem smartly, however, the area where I really lack experience is project management where other developers are involved (which is why I'm here asking all of you wonderful people for advice).

I made it sound like every student who comes into this office is a complete dimwit. There's been some bad eggs in here, but the majority of students I've met are intelligent, want to learn, and passionate about the work. Some are just starting out though, and they don't know what they don't know. And that's okay. When I first started programming, I was no better off!

War es hilfreich?

Lösung

It takes longer to clean up a mistaken than it does to pre-check it. If you're dealing with developers who are (possibly) unskilled or unaware of good practice, that means they should not be able to alter the (master) codebase until their code has been looked at by someone experienced.

You didn't want an explanation of methodologies, so let me skim over that part: use agile tasks to set up different features that can be developed independently.

Start using feature branches, so that everyone works on a separate branch. When a task is finished, the developer is not able to merge their code to the master branch. If you're using Git, they can still launch a pull request. Otherwise, use whatever method of tracking finished tasks(/branches) that takes your fancy.

Then we get to the review process. What you're question is a bit vague on is whether there are also experienced developers whose judgment can be trusted more than the students'. So let me elaborate either way:

If there are experienced developers, task them with reviewing the code of finished tasks. If it's good, they can merge it into the master branch. If it's not, they can either refactor it themselves or give feedback to the developer as to what needs to be improved.

If there are no experienced developers, then you're always going to be running into problems. If there is no one to spot good code from bad code, it's impossible to keep up code quality.
The best you can do is have review meetings, where developers present and explain their implementation in front of the other developers. While this cannot guarantee to prevent every issue (e.g. if all developers have the same misconception about good practice, it will still prevent the majority of issues (e.g. if at least one developer has the right idea and can articulate it; or when the problem stems from developers understanding the problem differently from each other)

How does one foster quality, efficiency, and communication in such a workplace?

  • Quality - Review the code by experienced developers. In absence of experienced developers, make it a group review to at least cover your bases as best as you can.
  • Efficiency - If you set the independent tasks correctly, you minimize people having to wait on each other. In an environment where not everyone is available at the same time, I assume you're dealing with a lot of "waiting for person A" delays. Follow up on developers who are not making progress, only to check if they need help or even just allow them to vent their frustrations (those frustrations can reveal misconceptions about avoidable issues).
  • Communication - Set an open door policy so developers can ask someone for help, feedback or inspiration. In absence of a qualified mentor, try to facilitate team interaction (you can of course still do this even if you have a mentor available, but the importance of doing so increases in absence of a mentor). Especially in a situation where people work remotely and on different schedules, developers are often not close to their coworkers and tend to not communicate amongst themselves. Even a handful of social gatherings can do wonders for improving work-related communication at other times.

Andere Tipps

The biggest thing for that sort of environment where people are new and likely to leave is mandatory code reviews.

They help spread knowledge of what should be done. They help prevent the worst code from getting into the codebase. They promote consistency in implementation.

Because with that much turnover and inexperience, communication is more important than it usually is.

More of an idea than a solution, but find one critical section of the codebase that contains similar features and elements to projects your student developers might do and clean it up VERY well. One big problem with new developers is that they do not know the norms and conventions of the codebase, and they will look at other code to get an idea of how to set up their own. Having a lot of newish developers working in a messy codebase means they will see the mess and think that's acceptable or the best way to do things. Bad practices then perpetuate themselves even in a high turn over environment.

By having at least one pristine, well written section of code (or even just one file), you can tell your student developers to use that as an example of best practices. Tell them you will be thrilled if they can write code similar to that, and that much of the other code might not be a good example of the right way to do things.

Adding comments or other documentation with an explanation of why things are done a certain way will also help new developers get up to speed more quickly with better code practices.

Continuous Integration -

This is a practical and conceptual framework for incremental and flexible implementation of team tools, skills, and processes.

CI is the idea of a work flow from writing code to deployment. These tasks are conceptually and actually independent.

CI is automation, in particular. This has profound implications for quality and productivity, starting at the point where code is typed on the screen.

  • CI task implementation can be addressed independently, in detail, and simultaneously. Focus can shift as needed.
  • Do not introduce a soup-to-nuts CI tool
    • Y'all will be distracted by process and tend to whitewash the encapsulated task-skills.
  • Introduce things on a bang for the buck basis

  • Expect to be the full-time change agent. Become the leader; not just a manager, not merely the senior coder.

  • Be strategic

    • The Holy Grail of CI is a hands-off, compile to deployment automation. They can't FUBAR it if they can't touch it.
    • Training and training materials.
      • Document processes.
      • Create a Programmer's Manual, let it evolve organically.
      • Mandatory.
      • Exploration outlines targeting specific skills and the code base itself.
    • Instill professional programmer values, such as:
      • TDD absolutely creates quality
      • Code reviews includes all artifacts: comments, commented out code, unit tests, etc.
      • "I'm embarrassed at how many bugs were found"
      • Objectivity is not stifled by the sense of personal code ownership and the fear of "offending" the owner.

  • Be tactical

    • Discrete CI tasks can themselves be automated, for example a version control commit triggering compile and unit tests.
    • Automation-enforced rules, such as code formatting.
      • Beware of too much pedantic minutia. The tool will start to be ignored. Modulate rule enforcement so it's not overwhelming.
    • Implement Test Driven Development right away
    • Prioritize and emphasize each change
      • Don't assume key knowledge and skill leaps simply happen.
    • Do not allow urgency to subvert proper implementation
    • Lead the change and follow through
      • New guy orientation and some minimal training is necessary.
      • Explicit training and unambiguous guidance for new things
      • Train at least to some minimum, notional, standards. Doesn't have to be real formal but a random walk through YouTube is not training. Personally verify - again eschew formality.
    • Be the code reviewer, review all code.
      • Explicitly guide challenging bug fixes and share notable learning experiences.
    • Rigid flexibility. Sorry, had to say it. But it's true.
  • Create culture
    • Have professional expectations
    • Standardize tools
    • Emphasize learning over production metrics
    • Be a mentor
    • When introducing change, simply depending on individuals' initiative "to make it so" subtilely subverts team development. A cohesive team's identity includes its common: tools, knowledge, and skill level. Mutual respect grows to the extent each member embraces theses as worthy values. The team leader is the model, it is inescapable; do not model a "whatever" attitude and expectation.

The Road to Quality

  • Unit testing

    • key to Test Driven Development
      • Reading whole books about it is not necessary
      • This should become the coding paradigm
      • As the leader you must keep at it until everyone makes the "unit testing leap of faith." That paradigm shift from "I'm writing twice the code!" to embracing its awesome productivity.
    • Unit testing was mandatory in our shop. But many didn't do it because they didn't want to. Management's lack of conviction sent the message that unit tests don't really work anyway.

  • Version control

    • I'd put this first but unit testing is easier to get started with
    • do not delay other initiatives because version control is not so easy
    • Make a version control plan.
      • You must write it down.
      • Do this even if it is as simple as "throw everything in the trunk and no branching."

  • Code Reviews

    • This has the greatest potential for improving code quality in detail.
    • Use a 2 review process.
      • I was very surprised at how many bugs a 2nd review catches.
      • Trust but verify. Run the code. Why should you even have to say this? See immediately above.
      • Initially you will be the only reviewer. Have the team watch you review "live." They'll never learn how to think otherwise.
      • Soon you will be just the second reviewer. As individual skills warrant have them review; eventually both reviewers. You of course will always be looking at the code, without exception.

  • Refactoring

    • This is a distinct, formal discipline.
    • Refactoring: Improving the design of existing code by Martin Fowler
      • Codified refactoring recipes that ensure induced-bug free code change.
      • Begin a professional library with this book.
    • Formality aside, introduce it ad hoc through code reviews

  • Capture your environment

    • Baseline tool configurations: version control, IDE, CI tool, OS, etc.
    • Source code, documentation, configurations should sync in version control.

A Word About Process

Agile (and its sub-genres like Scrum): Forget it. "You are agile, you do not do agile." See these by Dave Thomas, one of the original signers of the Agile Manifesto.

Given small, inexperienced teams my spidey sense goes off when I see team integration tools like Visual Studio Team Services. My experience is limited here but I sense stultifying, superfluous, rigid process imposition. I know many use these things to great effect but beware potentially buying a solution looking for a problem.

A Word About Tools

Just me. Not from those "Best software tools now..." click-bait honey pots.

Jenkins

A CI integration tool. Web based, widely used. Essentially, through a web GUI you custom-configure and automate the various tasks and execution order like compiling, running unit tests, updating version control. It is very A-La Carte so it is amenable to your nascent CI environment.

Version Control

I prefer Mercurial over Git. This blog post is why I originally picked Mercurial: Git is MacGyver, Mercurial is James Bond

Subversion is good. Mercurial & Git have a different architecture which is superior to Subversion's.

Integrated Development Environment

Here is a big fat consideration if everyone uses different coding tools: There Ain't No Such Thing as Plain Text

A Word about a Professional Library

The internet is broad, shallow, and disorganized.

  • Code Complete by Steve McConnell
    • Make everyone read the middle third.
    • Has an appendix of suggested professional books.
  • Refactoring: Improving the design of existing code
    • Codified refactoring recipes that ensure induced-bug free code change.
  • Software Failures. No specific recommendation but it should be stories vis-a-vis a treatise.

i propose to use another methodology to manage your process, since as you say it's impossible to schedule meetings (which is absolutely important for scrum!). There is still nothing bad to make a good concept so everyone's knowing what's going on (probably using a vert prototype, too) and using waterfall model. Either way, communication is the biggest part of the work.

I would encourage you to use source control if you're not already. This allows you to see what was checked-in by each developer and allows regressing where a bug was introduced.

I would set up some sort of test suite. It could be test-driven-development where you write tests for each function you're committing, or it could be an automated way to run your application(s) and have them output the results to a file that can be compared to the desired output. If this is run after every commit, or run at least once per night, you'll find regressions quickly.

The final thing I would do is implement 2 policies: 1) all builds must have warnings set to errors and all errors turned on 2) All code must go through the static analyzer without producing any errors or warnings before it is committed. I'd even make this a pre-commit action. These 2 things will keep the code from quickly getting horrible in a number of common ways. (They don't catch everything, but they catch a lot.)

This will also prepare your students for what work will be like in the "real world" and instill some reasonably good habits in them.

Lizenziert unter: CC-BY-SA mit Zuschreibung
scroll top