Welcome to the Onshape forum! Ask questions and join in the discussions about everything Onshape.
First time visiting? Here are some places to start:- Looking for a certain topic? Check out the categories filter or use Search (upper right).
- Need support? Ask a question to our Community Support category.
- Please submit support tickets for bugs but you can request improvements in the Product Feedback category.
- Be respectful, on topic and if you see a problem, Flag it.
If you would like to contact our Community Manager personally, feel free to send a private message or an email.
Pair Programming, but with CAD?
For some reason, I've read about various software engineering and project management practices for years with an eye towards how to incorporate some of the ideas into mechanical engineering and product development. I suppose this is in part because many products I've worked on include firmware/apps etc in addition to the physical parts (and electronics). While the realities of 6-18 months to get a concept into high volume production are a bit different from pushing a build of some code live every week or two, I still see some opportunities to learn from other engineering practices.
One such practice is pair programming.
Or here's a quick definition from Wikipedia:
I've long wanted to try this with CAD. Onshape seems like a perfect tool for this. I'm curious if others have tried Pair CAD?
One such practice is pair programming.
Or here's a quick definition from Wikipedia:
Pair programming is an agile software development technique in which two programmers work together at one workstation. One, the driver, writes code while the other, the observer or navigator, reviews each line of code as it is typed in. The two programmers switch roles frequently.
While reviewing, the observer also considers the "strategic" direction of the work, coming up with ideas for improvements and likely future problems to address. This is intended to free the driver to focus all of their attention on the "tactical" aspects of completing the current task, using the observer as a safety net and guide.
While reviewing, the observer also considers the "strategic" direction of the work, coming up with ideas for improvements and likely future problems to address. This is intended to free the driver to focus all of their attention on the "tactical" aspects of completing the current task, using the observer as a safety net and guide.
I've long wanted to try this with CAD. Onshape seems like a perfect tool for this. I'm curious if others have tried Pair CAD?
Tagged:
2
Comments
At a higher level of borrowing computer science practices, Onshape enables Agile product design processes that are very similar to Agile software development that aren't possible with any CAD system that is not cloud-native. Slightly old but good PDF overview of Agile Product Design linked here.
I certainly like how working together reduces errors, and for us, has surfaced innovative workflows faster too.
I tend to prototype with a week or 2 week turn around this way I can burn through 50 iterations in a design period. I'm finding that converging on the best design happens best with rapid development and only hardening a design towards the end. Many build hardened designs from day 1 meaning they'll only get 3 iterations before they harden the design. I don't care how good they are, more iterations will lead to a better product. At least this is what I'm finding (be agile).
With 3D printing and laser cutting, you can build proof of concepts fast.
I'll never release a design without a 2nd pair of eyes. Maybe this is the "pair". A design review, no matter how painful, always comes up with different ideas and I'll never miss one. This isn't new to product design/development.
Collaboration, the one thing I've been longing to do. Having managed engineering teams in the past, you'll still need a lot of project management to herd everyone in the same direction. If there's a team of OS designers out there looking for help, let me know. I've been wanting to collaborate with OS for a long time.
The other main design process that pair has missed is life cycle. Can you track your progress and where you've been? How would you use OS to accomplish this?
I read the Ready Lab report about collaboration last night and wished more engineering projects had the thoughtfulness giving by Prof. Olechowski. Trying to get a team of engineers to build anything is challenging and requires good project management. She tried to make it work and got qualitative data from the exercise. My hope is that she goes to research project management with controlling the CAD environment. From my experiences, currently, this isn't done very well.
I think engineering isn't about picking inside CAD but involves purchasing components and having things made. Most engineers these days do their own CAD & drafting but it's still not their full task. Engineers read about new materials & products and then you try new manufacturing techniques.
As far as "pair" goes, most young engineers that I've worked with have their own ideas and they're not going to sit next to you while you click on a CAD model. They always have their own ideas but lack knowledge about how to make them real, purchasing & vender selection know how. I have their stuff made while having my stuff made setting up a competition between design ideas. Then there's a judgement day. I don't always win.
it sounds like you might be great participants in a future study
What actually got me thinking about pair programming for CAD in the first place was this article from the New Yorker! https://www.newyorker.com/magazine/2018/12/10/the-friendship-that-made-google-huge
I've recently been thinking about whether there are specific tasks/scenarios when pairing or synchronous collaboration would be most useful. Is it in the initial set-up? In the final quality checks? does it depend on the product architecture? I'm not sure.
Coming at this more from a firmware / software programming point of view, I think "Pair Programming" is a useful tool in the toolbox but for very specific circumstances.
These include burning the midnight oil to meet a deadline (pair programming can help maintain concentration towards a focused goal). Or when designing a very technically intricate sequence of activities. It can also be helpful It can also be of some help for activities that require mixed skills, although I understand that doesn't strictly follow the spirit of "pair programming", and these days prototyping tools can be very good and allows activities to be done asynchronously.
That said, I find that a very powerful force in design and engineering is empowerment of designers / engineers to have a level of ownership, pride, responsibility and accountability for their work (obviously within the context of being a part of a greater team, and their work being V&V'ed). Pair programming can detract from that somewhat, it can 'commoditize' their skills, and it would require a strong culture for it to be effective. I also find that implementation uses a different skillset to V&V, and that often individuals can be more predisposed towards one or the other of those activities.
I also wonder if paired programming provides better quality outcomes? It seems that mistakes are just as likely to 'fall through the cracks' with paired programming. For conventional asynchronous development activities, the person who does V&V is responsible for the activity being correct and fit-for-purpose. Who is responsible for the activity being correct and fit-for-purpose in the paired programming environment?
I remember first coming across paired programming with software development a long time ago. It was promoted as best practice at the time by those who were pushing it, but it seems that the idea never really took off in the way that was being predicted.
Again, I do find it can be a useful tool in the toolbox, but it's not one that I reach for very often.
It is an interesting topic. Much of these workflows may have valid analogies in historical case studies. For example, during WW2 when there was the highest motivation to smash out new and better designs on a regular basis, were they doing that by pairing draftsmen at the drawing board?
To be clear, I've never tried pair programming or pair CAD, per se, but I've been thinking a lot about it. In the programming world, I've read countless forums, hacker news threads, tweets, etc. There's definitely a love/hate reaction to the idea. There are plenty of quotes I've seen where people say it saved or massively leveled up their career and they can't imagine not doing it some of the time, or on the flip side, people who would sooner quit than do pair-programming ever again.
On the subject of ego in design and engineering - it's a powerful force, but not always for good. People need to be able to feel pride in their work, but there's a huge danger of NIH (not invented here) or blind spots to issues. There's also the hit-by-a-bus problem - as in what happens when your lead programmer or engineer or designer gets hit by a bus? If they are doing all the work on a particular system, no matter how well it's documented, that's a huge issue. As a manager, I try to encourage the team to become more familiar with and do work on the whole project, not just the parts/subsystems that they're focused on. I've been tempted to have people rotate from subsystem to subsystem, but I've never fully forced that. Also if you ever see folders, parts, versions, etc. named after people, that's a danger sign.
If you dig into some of the papers that @alison_olechowski392 and her co-authors have published, they show certain plusses and minuses in the calendar time vs person hours, as well as quality. Overall it seems beneficial. Unfortunately much of the studies are based on CAD users who are relatively neophytes - I assume due to the cost/complexity of recruitment. The studies are also all very small (numbers of participants, length of time) and the CAD models are simple.
I'm hoping to try some paired CAD out soon in a professional setting, so we'll see...
@S1mon that's right, we had real trouble recruiting participants for our experiment locally in Toronto. But recently we spent some time creating reliable ways to do remote experiments (leveraging Onshape and Zoom) which has expanded our ability to recruit pros. We've completed one set of experiments (solo design) in this way and look forward to launching a new experiment soon on collaboration with professionals. Stay tuned!
Agree that these are serious engineering management issues, and 'pair programming' is one way of potentially addressing those issues, but there are other ways.
Another way is with asynchronous design reviews. It's very common these days that no software gets committed to a repository without a full code review by another set of eyes. The same can apply to PCB's, ID designs, and any other project assets.
I guess it becomes a question of granularity. Do you do very fine grain and have somebody watching line-by-line as code / CAD is being typed or drawn? Or do you do very coarse grain where the totality of the project is reviewed after completion? Or do you have a granularity somewhere in between those two extremes? (Obviously these are not mutually exclusive, typically there will be multiple granularities employedto cover the V&V activities) Different situations will call for different approaches.
IMO, the gold standard is having a culture where your engineers and designers tap a colleague on the shoulder and say "Hey, I'm about to implement something that is very fiddly and critical, can you look over my shoulder while I do this and make sure I get it right?" or whatever is needed for the benefit of the project at the time.
Thanks, I'll check it out.
Good luck with it, I look forward to hearing how it goes.