How do I learn the right approach to implement half a feature? [closed]

Question

I lead a development team and I want to release our product as often as possible (Continuous Delivery).

In many cases, we have to implement a feature that takes longer to implement than the time between releases. I still want people to commit their code on a daily basis (Continuous Integration).

Many times implementing a new feature requires existing feature to be changed and the existing features, of course, still need to work, even if the new feature is not finished yet.

If the developer uses the right approach, they can adjust existing features carefully and all of the above is not a problem.

However, what IS the right approach actually? My own programming attuned mind tells me what to do for each individual case, but I need to learn more and I need some reading material that I can read and refer team members to read. Or any other method of learning the right way to learn this approach will do.

So that's the question. How do I make sure team members learn the right approach to implement half a feature?

I've searched for people claiming to have strategies regarding this, but haven't found it yet, except people writing a few random thoughts on the topic. Perhaps I'm not using the right search words or perhaps no one has made any authoritative guidelines on this.

Answer 1

I take a different view from the other answers on here already. I agree with you that you want to integrate changes from developers as soon as possible, and to keep testing the combined mix of code.

However, I do not agree that its right to ship code developed this morning, just because we are releasing this afternoon. That is a recipe for disappointed customers.

The solution is to have branches in your version control tree, and that you have a separate process to promote verified deltas from the develop branch to the release branch.

That way you get the best of both worlds. You have developers doing continuous integration, and the advantages that brings, you have stable code shipping regularly to the customer, and you have a new process that tests completed features in the developer branch, and if they pass testing make them part of the released product.

There are two tools that I am familiar that support these kind of processes well. If your development structure is simple, then git, with git-flow implements a good branching structure that works well in small to medium sized teams (perhaps 20 developers).

For larger development teams, or where a more complex branching strategy is needed to support multiple 'spins' of your product, accurrev is the best there is. The developers not involved in managing the changes will complain that its harder than sub-version etc... but it does support complex development environments.

Answer 2

There are two problems here: one is implementing half a feature; the other is keeping the shipping product working during continuous development.

Implementing half a feature

A strong overarching design will help with this. This lets you implement the feature with its boundaries clearly defined--e.g., APIs to adjacent bits of code, expectations about data structures, and an understanding of how and when the implemented code will be called.

Testing can include mocked up versions of the code for the other parts of the feature; this helps smooth the transition when you go to implement the second half.

Keeping the shipping product working

There are a handful of options here:

1. Turn the feature 'off' in the shipped product. Just because the code is in the product doesn't mean it has to be executed or presented to users. The downside is that you will not be delivering incremental value to your users, and you will not be getting feedback.
2. Reveal the edges of the feature to your users. Show what you've got, and provide some indication of what's to come.
3. Let users switch between new and old functionality. This sometimes requires maintaining two code paths that are end-user-ready.

Finally, if you are having trouble with any of these solutions, consider whether you have split the feature along the right boundaries. If you sliced things a different way, would it be easier to pull apart?

Answer 3

How do I make sure team members learn the right approach to implement half a feature?

By teaching them. (duh)

Learning will involve iteration: trying something, seeing how it works, and then modifying their approach to achieve better results. For this sort of thing, I would advocate design/code reviews. You get to see how the half-feature is designed/implemented and have the opportunity to give feedback. "This and that won't work because they'll break our CI; how about XYZ?", "Good job here, that's really clean."

Doing the reviews as a team will help everyone learn what you already intuitively know.

Answer 4

The biggest thing that will help you here is having a good separation of concerns so that as far as possible one area of code does not interfere with another.

This is a place where using Dependency Injection and programming to the interface really helps, so that you can have your current implementation of ISupportingFeature on the site and then when you need to create INewFeature that depends on a different implementation, you can just develop with the new implementation and maintain the existing one in production until it is well tested and ready to go live. Assuming you have your DI working off a configuration system of some kind this will allow you to have the same code in parallel in your system and be using stable code at all times.

In fact this configuration approach is described by Martin Fowler as a Feature Toggle.

Of course, the problem only arises if you are deploying all of the code all of the time. This is precisely the type of scenario for which feature branches were designed and although I acknowledge that Mr. Fowler frowns on them, I don't know that they are all that bad, especially if they are created and used in a planned and thought-through way.