Software development speed

Dev creates the code that Ops tests, puts into production, and later maintains, while Ops creates new work for Dev by sending code back for enhancements and fixes. The separation of Dev and Ops can lead to serious inefficiencies in the software development lifecycle, from duplication of work to the inadvertent creation of bugs.

DevOps seeks to remedy those problems by integrating the tools used by Dev and Ops, and automating many of their activities, including scripting, configuration management recording the versions of various software applications running inside a company and the updates that have been applied to each of them , quality assurance QA testing, and defect tracking. In DevOps environments, software developers can test their code before releasing it to operations because their software development environment is linked to the production and QA environments.

Consequently, developers can discover and remediate defects early in the software development cycle. They can also confirm their code will work properly once in production.

Despite the apparent benefits of DevOps, few companies have fully committed to it. Companies that take their automation efforts to the next level by integrating Dev and Ops activities and tools may supercharge software development and create a much higher level of customer satisfaction. The agile software development community may have popularized DevOps, but the practices can also benefit IT departments that follow the waterfall method.

Indeed, opportunities to make a shift to real-time DevOps abound, but there are some projects—such as those involving mobile, social, and big data—that likely beg for a faster and more integrated development and operations approach. Unless IT can find a way to accelerate delivery without sacrificing quality—and real-time DevOps is likely that way—IT departments will find the business increasingly bypassing them and going directly to the marketplace for software development services.

Establish the need. This is a problem because it can drive a wedge between the two groups of engineers. Alternatively, if engineers are operating in quality mode, and product managers are expecting features to be delivered faster, tensions may arise because the product managers will feel that their deadlines are at risk.

The engineers may feel like they are unfairly being asked to produce lower quality work for the sake of speed when they had expectations of producing higher quality work. Make sure that everyone understands when you are operating in quality mode, and when you are operating in speed mode.

Whenever the mode changes, i. Managing these expectations will make release cycles go much smoother, and keep your advocates for quality and advocates for speed much happier. In addition to software development speed and quality, a third dimension that may be considered is scope. Sometimes, towards the end of a release cycle, you might have to sacrifice scope in order to hit deadlines while still maintaining a high quality product.

Some examples of reducing scope are cutting out fancy transitions and animations, dropping support for older browsers, or living with performance problems. Hi there, my name's Eric Rowell.

I'm currently leading the data visualization efforts at Platfora. Hi there! Thanks for those thoughts. Good point about aligning the mode of everyone and changing it depending on the present needs.

There are many departments involved. Not all the departments would be technically savvy, mainly when we are dealing with enterprise projects. Software development has always suffered this problem of business-engineering communication during development.

Hence the need to have a clear, single point or channel of contact. Speed of execution gets affected when people across a team are left searching for answers from another department or unit. This might be due to awareness or simply lack of knowledge about who to reach out to. If there is a single source of information or a single point of contact, development speed is greatly improved.

This is especially true when the project involves cross-functional teams. We discussed precise requirements earlier. Parallel to that is feasible, doable requirements. Far too often, project initiation happens and with clear requirements as well. Maybe the technology is not yet there, and perhaps compliance is an issue. Maybe the relevant standards do not permit it.

Hence it is essential to choose only those features which are possible in the current context. This reduces technical debts.

The software engineering process in the early days was pretty simple. Hence a linear flow of development worked fine. The requirements were given ad-hoc. It was developed as a whole. The test stability problem is extremely hard to solve. Some functional automated tests are quite unstable and it is hard to localize the root of the problem.

We spent an enormous amount of time on test stabilization and re-writing, but still, we have some unstable tests. System complexity makes automated testing harder and slows down all development even more.

So there is a very nasty feedback loop here. Some of them do, but in general, most of them enjoy the freedom and dislike rules. Experienced developers understand that some rules are really required. Cowboy coders just ignore the development process and move forward as they want. That is not always bad. If you work alone or in a tiny team it is OK, but in any serious development team, it will lead to more complexity and more chaos. Cowboy coders tend to cut corners and move forward as fast as possible.

I was a cowboy coder. I loved to see an implemented solution and I tended to sacrifice code quality for that goal. Extreme Programming, for example, is a highly disciplined process. It demands full energy and maximum attention, but it delivers great pace and code quality in the end. Sometimes it is absolutely necessary to boost development in the short run.

For example, you have an important expo or an important customer that insists on a release at a specific date. From a business point of view, it may be OK to trade quality for speed. You should understand that there is no free lunch. Short term speed boosts may lead to long term deceleration. A deadline sets a goal and in most cases, this goal is to release new functionality. Deadlines impose time pressure. Time pressure forces us to focus on a deadline goal — functionality. We cut corners, write not so good code and test less.

This leads to higher technical debt and more complexity. Pretty clear. So deadlines can be used for short boosts, but with great care. Now I will share a quite controversial thought for all people familiar with agile software development: iterative development is a set of mini-deadlines.

Indeed, timebox means we have to complete a defined set of work by the end of an iteration. Think about that. Does it imply the same consequences as a big fat Deadline? Not really, but similar. If a team committed to 9 user stories in sprint 4, it tries to complete all of them. But Scrum, for example, demands commitment, thus applying psychological pressure. People start to cut corners.

On a small scale for sure, but still. It is not always bad, as we already know, but it is good to be aware of this counterproductive side effect. An obvious and easy well… way to increase overall productivity is to work more. By working more hours we can complete more stuff and release earlier. Jason Fried thinks that this approach is totally wrong:.

It just means you work more. Workaholics wind up creating more problems than they solve. The balanced vision states that some overtime is OK. But in the long run, this practice will fail and recoil is inevitable.

The only extremely rare exception is when we have our production servers down or some blocking bug lives. Passion is good. Passionate people really care about their work. They do all they can to write good code, invent great solutions and move things forward. Every employer wants to have as many passionate people as possible. Passion is not all-shiny though. Burnout is real, so it is much better to keep going in a balanced state. Otherwise, you may have health problems, psychological problems , family problems and depression.

How many interruptions you have every day? Software development demands deep concentration and focus. Programmers build huge models in their minds and every single interruption can break the model state, so it will take time to rebuild it. Focused work cuts all wasteful activities and helps developers to dive into the flow. It is quite unclear how team stability affects productivity.

Intuitively, we may think that stable teams perform better. In this case, our intuition is right. Research done by Rally states that:. Why is that? Every team has a life-cycle. Tuckman defines 4 phases of a team development : Forming — Storming — Norming — Performing. It is obvious that a team is most productive in the last phase — performing. If you rotate team members, you break the team and all these phases will repeat again. And again. In the worst case, there are no such things as Norming and Performing phases, just ongoing storms caused by rotation.

It is interesting to think about pair rotations in pair programming. Every day developers work in different pairs. Is it really good? We tried that at Targetprocess and it was awful. Now I understand why. Firstly, there are personal preferences and some people are extremely unproductive in some pairs.

Secondly, it is hard to build good relations fast when you rotate every day. In fact you lengthen all the 4 phases mentioned above and the true Performing phase may never happen. How stable teams perform in other areas? How about soccer? Here is a fascinating research Stability and Performance in Football Teams pdf. The conclusion is pretty clear:. About a year ago we decided to form four stable teams. We decided to re-form these two teams. Looking back it was a very good decision.

Now all four teams are demonstrating good productivity in the Norming phase, but it took several months to overcome the Storming phase. As we already discussed, stable teams are better. Stable teams are quite independent and not very large. In our company, the typical size of a team is 6 people. Communication inside this team is really dense, however, communication between various teams is not so intensive.

Here is a typical open space. Many people in large areas. You hear voices from all directions. Phones ring. Somebody crunches a cookies wrapper. Hot discussions born and spread between tables. People greet each other right near your workplace. Sounds familiar? It is hard to concentrate here. I will go and buy those expensive noise-cancelling headphones. Right now! Now compare that to the small rooms for people working together as a team. Phones ring not so often. There are less voices around. Most talks are quite important to hear and osmotic communication works, finally.

Whiteboards are right there on the walls and hot discussions are relevant and immediate. I think this setup is the best. It is true that private office enables maximum focus. However, it breaks communication. People are lazy enough to not get up and go ask a question.

If you can ask a question in a snap, that makes a big difference. Something pops up in the right corner and you move the eyes to check it. Focus is lost. A red balloon appears on a Skype icon, and you struggle with a sense of urgency that annoys you and forces you to open Skype and check the message.

They are small and chronic, they are embedded into your daily flow. The truth is these small interruptions are dangerous enough to transform a productive day to the unproductive one. You check, reply, try to focus, check again, reply again, try to focus — all you have at the end of the day is several replied emails, many skype discussions, few lines of code and endless attempts to focus.

How to fight that? When you are really going to focus and code something, quit Mail, quit Skype, shut down all notifications services. Is it vital to see a new reply on Twitter or a new status update on Facebook? I bet it is not. I know that for sure since I have this problem myself.

In our company, we used Skype a lot. There were various chat groups. Every team has a chat. Looks like all of them are required, but the amount of messages is enormous.

We need all those communication channels, but we pay a high price of constant interruptions every day. A great communication channel is very targeted. The best scenario is when a message is received by people that really need it they can react somehow. However, it is not so easy to define this group of people. Smaller targeted chats maybe will work better than several generic chats.

Recently we switched to Slack. It has a better notifications system and is less annoying, but still, there is an intrinsic burden caused by chats. There are two types of multitasking: when you are coding and talking by phone and when you have several tasks to complete and switch from one task to another.

The first type is an obviously bad thing. The second type is bad as well, but we still multi-task. I personally work on several tasks every day. Context switch kills productive time easily:. How to solve this problem? Context switching should be reduced to a minimum.

The best scenario is to work on a single task until completion and only then switch to a new task. Easy to say, hard to follow. I think some tricks can help us here. There are scientific proofs that meditation helps pdf.

A viable alternative is to split work into chunks. Any re-work reduces development speed for sure. It is impossible to have zero re-work, but we can try to minimize it. Bugs in development are inevitable and testers work cooperatively with developers to find them as early as possible and get them fixed. It is important to find bugs earlier. In this case the developer has a fresh memory about the code and most likely will fix bugs fast.