I’m a career software and systems engineer. I’ve spent the last 15 years working in the automotive domain working both at the OEM as well as Tier 1 suppliers. Along the way I’ve worked on varied aspects of the automobile including body controls (lights, door locks, and anti-theft systems), safety critical systems, and Infotainment systems (radio and entertainment systems). Along the way I’ve had the pleasure to span the responsibilities of developer, lead engineer, researcher, and manager giving a multitude of perspectives on the day-to-day challenges.
Over the years I’ve found the pleasure of revisiting the brilliance of software engineering literature (especially Brooks, DeMarco, Lister, …). And the current call and challenge of researchers to make Software Engineering as structured and principled as other engineering disciplines. But again and again we return to Software Engineering is about people (especially the people that build it!). Whether it is as simple as Conway’s Law or Brook’s Law, again and again we understand that Software development is about people and patterns of communication.
Which gets to what I’m passionate about… Communication in software and systems engineering. I’ve observed two critical dimensions to this challenge…
- Organizational Communication – Project status, risks, and execution plans. We see agile methods and tools like Rational Team Concert really taking these dimensions on.
- Technical Communication – Developer projections of expertise. We’ve thrown all of these tools and technologies at developers but they aren’t always the way they think (especially cross-disciplinary communication). We see tremendous growth in the Domain Specific Tools since the original modeling tools of a decade ago were unable to disprove Brooks’ statements on the Silver Bullet.
I’m motivated on working with teams and individuals to clear the communication barriers and become more successful. In essence this is amplifying their own inherent expertise and making it most effective. Every challenge (and organization) is unique, but ultimately there is an answer that by introducing change is a benefit to everyone especially when starting whit the developers!
You can contact me at rcbaillargeon at acm.org