developer

Article: SharePoint Development in 2017

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.

Introducing the Development Options

The last four years in SharePoint have been tumultuous, to say the least. Of the five models available, three were introduced in the last four years. These are the five models:

  • Server-Side Object Model (a.k.a. Server Solutions): Introduced in 2007 and available today for on-premises deployment, this model has the richest support and the greatest longevity, but puts a great deal of onus on the developer to write good code, because the code runs directly inside the SharePoint processes.
  • Sandboxed Solutions (a.k.a. User Code Host, Partially Trusted Callers): Introduced in 2010, these solutions allowed end users to write to a subset of the SharePoint API. These solutions had severe limitations but were designed to reduce platform instability with poorly-behaved developer code. It’s no longer available on Office 365/SharePoint Online and is not planned for further investments.
  • Add-Ins (previously known as “Apps”): Released with SharePoint 2013, these client-side-based applications run on other servers or in JavaScript in the browser, so they eliminate the challenges of server-side code. The complexity of this model, which includes the required wildcard DNS entries and authentication changes, required a different (and some say greater) developer skill set. Add-Ins are available both on-premises and online.

Full article at developer.com. Read more…

Developer Productivity: Managing Cycle Times in Iterative Development

Article: Developer Productivity: Managing Cycle Times in Iterative Development

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.

Iterative Development

It’s important to realize that even waterfall development was initially designed to be iterative. The idea wasn’t that you’d do something once and then never work on it again. However, if you have project managers on the team, for example, who are used to building a bridge, some of their experiences might get brought along. When building a bridge, it has to be built right and built just the one time. Thus, very early on, projects were pushed into one iteration and long cycles of design, development, testing, and release.

The agile movement has revived the need for iteration, and focuses on quick turns of innovation. Whether your iteration is a week, two weeks, or a month, this is a substantially faster iteration pattern than the monolithic waterfall projects from the distant past.

A Lesson from Manufacturing

It’s no secret that American car manufacturing got its clock cleaned in the 1980s and 1990s by the Japanese. Much has been made of the Toyota Production System—what is now most frequently called “lean manufacturing.” One of the often-overlooked components of the system was the ability to change over from manufacturing one item to another very quickly.

Part of the developer.com series, Developer Productivity. Read more…

projmanager

Article: Developer Productivity: Ensuring Productive Meetings

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.

It really doesn’t matter whether you’re using an agile software development methodology, waterfall, or a blending of the two that you call something like “Agile-Fall.” In truth, the meetings that you experience as a developer share common characteristics no matter what the methodology. Let’s look at agile meetings first.

Agile Meeting Types

Developers working in agile projects typically experience four basic kinds of meetings. The daily standup meeting is the most frequent, and therefore potentially the most time-consuming. The backlog, or estimating meeting, occurs each sprint or iteration so that developers can estimate the effort for each task and determine dependencies. Show and tell meetings occur each sprint to help demonstrate what’s working. These meetings are primarily designed for the clients, but often developers are asked to join to “show off” their features. The other meetings are “traditional” meetings, which may include organizational meetings as well as requirements-gathering meetings that developers get pulled into.

Standup Meetings

Everyone is supposed to stand up to keep the meeting short. Three questions are designed to elicit commitment and create opportunities for support.

Part of the series on developer.com, Developer Productivity. Read more…

flow

Article: Developer Productivity: Eliminating Distractions and Finding Flow

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.

Deliberate Distractions

In our world, we’re constantly interrupted. Our phone goes off with that latest alert from ESPN. It’s constantly vibrating from the stream of incoming messages, chirping from the latest text with our friends, and more. We ignore the phone vibrations from emails because Outlook conveniently pops up a toast notification telling us about the latest message. It’s stacked full of messages from the corporate HR department telling us about something we don’t care about, the thread of inane comments, and the SPAM that has become a part of our daily lives. More toast from our instant messaging tools pop up with notifications when our colleagues and friends become available.

Many developers feel the need to keep a social media feed open so they don’t miss out on something important. Whether it’s Twitter, Facebook, or something more business-related like Slack, we’re concerned that we’ll miss out on something important if we’re not connected. These channels generate more distractions.

Part of the series on developer.com, Developer Productivity. Read more…

 

trainer

Article: Ten Technical Trainer Interview Questions You Should Know

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.

From the developer.com series, Top Ten Interview Questions. Read more…

deploy-devops

Article: Ten Deployment/DevOps Interview Questions You Should Know

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.

From the developer.com series, Top Ten Interview Questions. Read more…

webapp

Article: Web Application Vulnerabilities

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.

Article on codeguru.com. Read more…

QA professional

Article: Ten Quality Assurance Interview Questions You Should Know

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.

From the developer.com series, Top Ten Interview Questions.  Read more…

scrum-master

Article: Top Ten Interview Questions Every Scrum Master Should Know

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.

From the developer.com series, Top Ten Interview Questions. Read more…

developer

Article: Top Ten Developer Interview Questions You 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.

From the developer.com series, Top Ten Interview Questions. Read more…