Has anyone done CSDP certification?

Question

I was looking at some certifications that can potentially enhance my knowledge and market value as a Software Engineer. IEEE's Certified Software Development Professional (CSDP) caught my attention. When I looked on the net for any user experiences with it I couldn't find anything substantial. Doesn't seem too popular. And I certainly havent heard of anyone in my organization or friends circle who have done it.

I would like to know from community members if anyone has done this certification and their experiences with the same. Was the certification useful in terms of knowledge. Did it add weight to your resume (not deadweight!)?

Answer 1

I currently hold the IEEE Certified Software Development Associate (CSDA) certificate, and I'll be sitting for the CSDP exam when I'm eligible (I still need ~2-3 years of experience).

Like any certificate, it's only proof that you know certain topics, by the book form. They don't really say much about how you'll perform on-the-job. Your past work history will do that far more effectively.

For me, I took the CSDA because it correlated very closely to my university's software engineering program. By taking and passing the exam, I validated that not only did I know the material relevant to my field to the depth and breadth mandated by my university (which is proved by the completion of the degree program), but also to the depth and breadth recommended by an internationally-recognized organization that has an extensive experience and knowledge base in the field of software engineering.

How employers view certificates varies widely, between industries and organizations. Some industries favor certain certifications over others. Organizations also place their own weight toward perspective employees and the certificates they hold. In the comments on your question, Brian Driscoll posted a link to a list of companies that hold CSDP/CSDA certificate holders. If you notice, a lot are involved in defense, medicine, telecommunication, finance, and general engineering (building hardware systems). These are industries where compliance with regulations and precision engineering (low tolerance to failures or defects) are important.

If I was going to get certified, I would definitely look at world-recognized organizations such as the IEEE Computer Society, the Project Management Institute (PMI), the Software Engineering Institute at Carnegie-Mellon University, the Information Systems Security Certification Consortium ((ISC)2), and universities that offer professional/graduate certificates as opposed to companies that do corporate training.

When you are weighing the certifications, you need to determine where you want to be down the road and what kind of knowledge you need to have and need to demonstrate that you have. For example, the IEEE CSDP certification covers the breadth of software engineering - you are demonstrating competency in the key topics identified in the Software Engineering Body of Knowledge. It's a good, general certification for anyone from a "down in the trenches" developer to a software lead or software project manager. However, the SEI offers intensive certificates on topics such as the CMMI, process management, and process improvement (among many others). For someone like me, who works in the defense industry where all of the players undergo CMMI appraisals, getting training and a certificate from the organization who developed CMMI and trains the CMMI appraisers might be valuable. If you're not working in an organization that applies the CMMI, this certificate isn't that valuable.

Answer 2

Here's the short and the sweet: It is going to gain momentum.

Alot of employers have placed a great deal of emphasis on past experience, the schools you went to, and -- for lack of a better way of saying "gotten burned". Contrary to popular belief, software development is not nearly as creative an endeavor was many of us in technology would like to believe. In the areas where it does allow and even require creativity, it typically requires understanding end user personas/stories, system requirements, business domains, economics, software engineering process and software architecture well before you ever get into the software construction [coding].

Since the rise of the Agile Movement, the consensus has been mistakenly to place emphasis on coding & developer first. This has actually been a misinterpretation of what the Agile Manifesto authors were trying to get at though it might be difficult to glean that from the Manifesto. Agile has borrowed heavily from and even directly adopted LEAN principles. LEAN does focus on the implementation employee, but only from the perspective of the fact that these individuals are closest to the firm's [read: contractual client's] actual customers.

Why is this distinction important? Implementation employees feel the impact of many decisions -- both good and bad -- directly. As such, they're uniquely positioned to make simple changes that can have a dramatic impact on performance and quality. Sadly, they often are not fully engaged for their knowledge of the end-customer, leaving many opportunities to improve performance and product quality on the table. LEAN's mission is to consistently deliver greater value to the end-customer by achieving ever increasing levels of effectiveness through the removal of waste increasing delivery speed and quality improvement. Agile pushed the envelope on waste removal within the software construction space, but true effectiveness from the end-customer [as well as the contractual client's end-user] perspective has been minimal.

To that end, it is worth noting the positive achievements in speed & quality such as a clear improvement in Code Craftsmanship [blending science and art] have driven us forward on the construction front, but in the process we've lost sight in what is important -- the customer. And I don't mean just the end user, but the enterprise's end-customer. Just as in LEAN, everything starts from the actual customer and works its way backwards. So what does this have to do with IEEE's CSDA & CSDP? Plenty.

To begin with, it often takes a person who is rooted in the type of understanding reflected in the engineering disciplines to fully grasp that a process must always be focused on the overall goal while taking into account its actual effectiveness, milestones & quality attributes. If you're missing anyone of those traits, you're falling short of delivering full value to your contractual [enterprise] client, which in turn could generate a tidal wave of events that decrease value to the end-customers/firm's clients. Not good.

Further, the ability to take on leadership responsibilities [which if you have a self directed team {as Agile mandates} requires everyone be capable of leading to some degree] usually requires a good breadth and depth of understanding of the subject matter at hand, the functions which it interacts with, as well as the the ability to communicate this knowledge to multiple stakeholders from a variety of backgrounds. The reality is that no matter what is in the job the description, people expect that developers are engineers deep down. That they are smart, talented people with breadth and depth to their skillsets, which include mastery of their primary activities, as well as the ability to understand and solve for any contractual client's problem domain.

So why the big ol rant about Agile when discussing the CSDA & CSDP? Simple -- Foundation. If you have a team of CSDA's and CSDP's, even if they somehow cheated, they still will have some decent knowledge of where all the processes and disciplines within Software Engineering go, why they are there, and when to revert back to them as a means of unifying understanding before marching forward in a new direction. That Foundation will create an opportunity for consistent delivery of Software development practices, across SDLC methodologies and ability to pivot between and/or combine SDLC methods quite easily. IEEE has created an avenue for computing professionals -- whether engineering majors, CS graduates, IT pros, or self taught developers -- to unify and demonstrate a basic understanding of the Software Development, Delivery, and Decommissioning process as an Engineering discipline that is worthy of respect and should be treated with deference. And because of these factors, it will gain momentum.