Tag Archives: Development

How To Create A Complete Internal Developer Platform (IDP)?

Improving And Simplifying Software Development With Jenkins X

Software development is hard. It takes years to become a proficient developer, and the tech and the processes change every so often. What was effective yesterday, is not necessarily effective today. The number of languages we code in is increasing. While in the past, most developers would work in the same language throughout their whole carrier, today it is not uncommon for a developer to work on multiple projects written in different languages. We might, for example, work on a new project and code in Go, while we still need to maintain some other project written in Java. For us to be efficient, we need to install compilers, helper libraries, and quite a few other things.
Continue reading →

This post is part of the “Behavior Driven Development (BDD): Value Through Collaboration” series.

Introduction

The goal of software projects is to deliver value to stakeholders. Even though that might sound an obvious statement, it can be easily forgotten in traditional Waterfall projects. The very nature of the Waterfall process fosters the creation of different departments whose job is to receive work from the previous stage, produce something, and pass it on.

A simplified Waterfall model would be:

Requirements specification resulting in requirements document
Design resulting in software architecture document
Development resulting in actual software
Integration
Testing
Installation
Maintenance

Each of these phases tends to have separate teams and departments. BAs work with requirements, architects write design documents, developers code, integration engineers integrate, testers test, and someone installs the software. Each of these departments is waiting for others to produce something, to start working on their artifacts and, once finished, to pass it on to someone else. The value for the stakeholders is, in many cases, unknown or forgotten. Most people involved in such projects are concerned about “doing their part” and throw it “over the wall” to those coming next. Moreover, artifacts produced by one team are often not used or understood by another.

Continue reading →