When SharePoint first came out in 2001, development for the platform wasn’t easy. It was ASP—not ASP.NET, which was the first development approach for SharePoint. In 2003, the platform was migrated to .NET, but it wasn’t until 2007 that it had a proper customization strategy in the form of features and solutions. The world has changed since then, and SharePoint has had several development models come—and one has both come and gone. In this article, we’ll look at the development models available in SharePoint and Office 365 development and explain why one would choose one model versus another.
Thus far in the series, we’ve focused on managing productivity at an individual developer level. However, sometimes developer productivity results from the best management of the developers and the rest of the team. Measuring individual developer productivity is convenient because it tells you how well a single developer is performing. However, even the best developers can perform poorly when they’re put into a cadence that doesn’t work for the project or the organization. Here we’ll look at iterations, and how quickly we cycle can make a big difference.
If you work in an organization, you’ve experienced bad meetings. These soul-sucking, time-crushing meetings leave you deflated and wondering if you’ll ever be able to get anything done. Learning how to make sure that developers are only in the meetings they need to be in—and that the meetings that they’re in are productive—is a key way to maintain developer productivity.
Every new development tool promises improved productivity. New languages promise better developer productivity; but, sometimes, the key factors for developer productivity aren’t the tools, the computer, or even the additional monitors. Sometimes, the keys to allowing developers to get more done are psychological factors that we’ve known about for decades.
At the tail end of the process, the criticality of training and user assistance is often lost. The role is often underfunded and overworked – but intensely valuable to making the software work for the users. The Anatomy of a Software Development Role: Training shows how the role brings the development home to the users.
Bridging the gap between development and the infrastructure teams is the deployment specialist. These days the job is often titled DevOps specialist, indicating how these two worlds are being merged. You can see how this role started in Anatomy of a Software Development Role: Deployment.
In today’s world, most developers are building Web applications or applications that expose Web services publicly. Most applications are connected to the Internet in some way or another. However, most developers haven’t been formally (or informally) trained in Web application security or which vulnerabilities they should look out for.
Perhaps the most challenging role in the software development process is that of the quality assurance professional. It requires a set of soft skills for dealing with developer egos and hard technical skills to get bugs to scurry out of their hiding places and into the light. Candidate for these roles can expect questions about their hard skills including the tools that they use. For more about how critical the quality assurance role is, check out Anatomy of a Software Development Role: Quality Assurance.
Scrum master isn’t a magical software development role but it’s a different one. Scrum masters keep the agile development process running by leveraging a set of psychological principles that helps everyone be their best. Good scrum masters know the concepts behind the behaviors and those are at the heart of the ten questions every scrum master should know.
It seems like anyone that knows how to copy code from an Internet search or put a semicolon at the end of a line calls themselves a developer. However, how do you sort those that understand development from those that just want to. The answer, may be in these ten interview questions that every developer should know. Developer is the workhorse role in the software development process as the Anatomy of a Software Development Role: Developer article points out.