Sarah Taraporewalla's Technical Ramblings - Latest Comments

Re: How Gender Stereotypes Influence Emerging Career Aspirations

tshimbiluni — Sun, 06 Mar 2016 05:52:21 -0000

thanks but the information I am looking for it is not enough

Re: JAOO and Women: Attendance at Conferences

Sophie — Thu, 06 Sep 2012 00:57:12 -0000

I’m a woman, a speaker, and yes an attendee to a lot of
conferences, but I am not much of a techie lass. Maybe it just depends upon the
personality of the target attendees. Yes, I agree it pays a lot to consider the
marketing strategy to promote any conference.

Re: Experience Report: Branch by Feature

Simon Hurley — Thu, 30 Aug 2012 09:24:31 -0000

Hi Sarah,

Thanks for this article. I've had many-a-conversation about this recently at my company as our new product was developed using feature toggles, and our legacy using feature-branches. Feature toggles work fantastic for us in the sense that we can have many developers working on future features, and at any point in time we can deploy whatever features are complete, and toggle-off those that aren't. Our weak-point is our integration testing coverage. We have numerous people now automating our integration tests, but until we have good coverage whenever we do a release we are at risk to an undeveloped feature that hasn't been feature toggled correctly creeping into production. For the time-being, feature-branching has the advantage of restricting unknown changes being released. For now we're trying to make integration testers more aware of what has changed in an effort to improve release reliability.

Re: JAOO and Women: Attendance at Conferences

Timothy Parker — Tue, 17 Jul 2012 03:24:41 -0000

I think, just think, that it depends to the person if he/she has the confidence to face a lot of people and speak in front plus the knowledge of what he or she's going to say in front of a lot of people joining the conference. And I salute to every person whose conducting conferences smoothly without boring the people joining it. Sometimes there are speakers who really is boring and I have attended a few. I am an entrepreneur and has joined a lot of conferences I agree to you at some point but honestly the majority I joined I was able to learn from it and up to now I apply it on my work.

Re: How Gender Stereotypes Influence Emerging Career Aspirations

Lilchikmdc — Mon, 07 May 2012 05:24:22 -0000

thank you 4 the information but it was not what i was looking for

Re: Experience Report: Branch by Feature

Klke — Thu, 03 Nov 2011 13:32:50 -0000

Even if your branch is 30 commits long, with git you can progressively merge it. What's the problem?

Re: Experience Report: Feature Toggling

SKi Helmets — Thu, 27 Oct 2011 21:23:11 -0000

Thanks for another great experience report, I've followed this from your branch by feature report.

Re: JAOO and Women: Attendance at Conferences

Millie — Sat, 24 Sep 2011 12:24:01 -0000

I think as women we often have the misconception we have nothing to say. I attend and speak at conferences fairly often, but was hesitant about it years ago. At first, I believed I had little to add to the conference and even less to say. Then I learned it's also about how you say it. Having a fresh, new way to present information helps people see it and understand it in a whole new light. Doing a bit of research first to diversify your approach also helps.

Re: Experience Report: Feature Toggling

Gavin van der Merwe — Wed, 31 Aug 2011 12:39:03 -0000

It is an empirical fact that branching costs both time and money. Branch by abstraction reduces this cost and in fact enables your consumers with more options provided you do it right. As always the question is how far do we take it and how temporal should they be? Are the switches part of your build process(ie. build flags) or should they in fact be run-time switches? You decide, the fact still remains that merging code into 2 devolving sources is more expensive than maintaining an abstraction seam with a plugin architecture of some description(the weakest of which is using an IoC container).

@James McKay -> Both abstractions are in fact live code which should always be ready to go to production which means they should in fact both be tested and perceived as live code. Your argument about this being technical debt is very moot I think because you have decent enough abstraction seam's in your code it is merely a case of deleting a particular implementation along with its unit tests. I recommend you read a book on Continuous Delivery.

@Michael Feathers -> Perhaps you might have missed the point to branch by abstraction. I agree with you that every branch should in fact have an end date(or in my case no existence what so ever), although comparing branch by abstraction to build flags in C#/C++ kind of makes me think you have missed something here. These are baked into your artifacts right from the outset of your continuous pipeline in the build step. Surely we would aim for something a little bit more malleable or open to change than this? The more runtime switchable they are the more flexible you can be, wouldn't you agree?

@Bernd Eckenfels -> I think you are on the right track, I do it with IoC containers but you could implement it very much the same fashion as you described. Outlining your abstraction with a pattern of some description is a start! :)

Re: Experience Report: Feature Toggling

Bernd Eckenfels — Mon, 01 Aug 2011 06:26:14 -0000

In case you wonder, I would use the more usual term for this: you follow the strategy pattern where you allow an implementation (strategy) to be replaced by another. This usually requires a factory pattern which delivers you strategy, this is where you implement the code for the toggle. In a Java system one option for toggle is to simply name the class name to use for a given interface (and bang there you are at the third pattern, the Java/JAR service provider pattern: http://download.oracle.com/... Provider).

http://www.netobjectives.co...
http://c2.com/cgi/wiki?Stra...

Re: Experience Report: Feature Toggling

Sarah — Sat, 16 Jul 2011 17:13:06 -0000

Thank you to everyone for the comments and feedback. I have updated the post to include answers to questions that have arisen here and other places.

Re: Experience Report: Feature Toggling

Michael Feathers — Fri, 15 Jul 2011 13:47:23 -0000

Feature Toggles are nice, but I really think they should come with an expiration date. Otherwise, it's likely that people won't do more integrative refactoring. In effect, it's a lot like the use of conditional compilation in C++ and C#. The mess potential is high.

Re: Experience Report: Feature Toggling

James McKay — Fri, 15 Jul 2011 08:57:51 -0000

Feature toggles are great for some of the things you have mentioned there. However, I don't like the idea of using feature toggles purely as a means to avoid feature branches.

The big risk here is accidental exposure, especially if you are working on a large task which won't be complete for several weeks and you need to produce interim releases in the meantime. If the wrong version gets activated on a production server, you could easily end up with security vulnerabilities, exposure of trade secrets or other confidential information, or even data corruption if you have extensive database migrations in the mix as well. The more servers you have to configure, and the more feature toggles you have in place, the greater the risk of making a mistake. Additionally, feature toggles create extra technical debt since you have to remember to remove them after you're finished with them.

Companies that manage to make feature toggles work (e.g. Facebook, Flickr, etc) tend to have them well baked into their architecture and backed up by a rock-solid change management process, and very often a whole lot of monitoring as well. If you don't have that, it's going to be a high-maintenance, high-risk hack.

I think it's a bit disingenuous to say "feature branches bad, feature toggles good." Both approaches have their advantages and disadvantages, and the important thing is to find what works best for you and your team. And many teams find that feature branches work just fine for them.

Re: Experience Report: Feature Toggling

Alan Parkinson — Fri, 15 Jul 2011 06:56:34 -0000

Thanks for another great experience report, I've followed this from your branch by feature report.

My only concern with feature toggles is the build up of risk from potentially dead code being left over from old features. How do you go about removing toggles, is this a business decision?

Re: How to decrease risk when designing integrated systems

Sarah — Fri, 15 Jul 2011 04:27:03 -0000

Hi Chris,

You can view the presentation at http://prezi.com/enquxwkdpg...

<div class="prezi-player"><style type="text/css" media="screen">.prezi-player { width: 550px; } .prezi-player-links { text-align: center; }</style><object id="prezi_enquxwkdpgvf" name="prezi_enquxwkdpgvf" classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" width="550" height="400"><param name="movie" value="http://prezi.com/bin/prezil..."/><param name="allowfullscreen" value="true"/><param name="allowscriptaccess" value="always"/><param name="bgcolor" value="#ffffff"/><param name="flashvars" value="prezi_id=enquxwkdpgvf&lock_to_path=0&color=ffffff&autoplay=no&autohide_ctrls=0"/><embed id="preziEmbed_enquxwkdpgvf" name="preziEmbed_enquxwkdpgvf" src="http://prezi.com/bin/prezil..." type="application/x-shockwave-flash" allowfullscreen="true" allowscriptaccess="always" width="550" height="400" bgcolor="#ffffff" flashvars="prezi_id=enquxwkdpgvf&lock_to_path=0&color=ffffff&autoplay=no&autohide_ctrls=0"></embed></object><div class="prezi-player-links">

SDC2011: The three pronged approach to integrating systems on Prezi

</div></div>

Re: How to decrease risk when designing integrated systems

Christopher Marsh — Fri, 15 Jul 2011 04:23:09 -0000

Hi Sarah

I saw you give this talk at the Canary Wharf .NET User Group, and loved it. I don't suppose your slides are publicly accessible, by any chance?

Many thanks

Re: Experience Report: Feature Toggling

Alyssa Coghlan — Fri, 15 Jul 2011 02:50:37 -0000

In a certain project that shall remain unnamed, I used exactly that approach to deal with a longstanding hardware vendor bug - hid the code that workaround the bug behind a config toggle, told the hardware team to request a config change on the operational when they finally rolled out the fixed firmware to the whole system (I'd already tested the updated firmware in the development lab to confirm that the toggle worked as desired).

Definitely a valuable thing to do, but you do need to be careful to guard against combinatorial explosion trashing your ability to test effectively.

Re: Experience Report: Branch by Feature

Sarah — Fri, 15 Jul 2011 02:04:21 -0000

I have added a follow up experience report on Feature Toggles http://sarahtaraporewalla.c...

Re: Experience Report: Branch by Feature

Adam D. — Thu, 14 Jul 2011 19:54:37 -0000

Responded here: https://plus.google.com/109...

Re: Experience Report: Branch by Feature

Sarah — Thu, 14 Jul 2011 17:40:12 -0000

Hi Adam

I have taken a while to reply as I wanted to give a thoughtful response, not just a knee-jerk reaction. Fundamentally, we are approaching this from two different philosophies. I am afraid, however, that I have not been able to decipher through all the noise on here and twitter what you believe are the advantages of BPF (as opposed to how it should be implemented). Without that understanding, I feel a little handicapped. I appreciate you taking the time to enlighten me.

As for a Continuous Integration, which I hope you agree to be the "antithesis" (for lack of a better word) of BPF, and what I am advocating I believe that the advantages include: identifying integration problems early, avoiding painful merges through semantic (as well as textual) differences, early warning of incompatible code, promotion of a co-ownership, encouragement of continuous refactoring. Additionally, each commit is treated as a release candidate, which means that the business can decide when a feature is complete enough to be deployed.

I am a firm believer that the development team should not get in the way of business decisions. In that regard, I believe that there is real value in giving the business the opportunity to decide when and what to release, and that be acted upon in a matter of seconds. From what I have experienced, merging the necessary features into the mainline when you decide to release slows down the release process, as after you merge it (assuming that it is trivial and you have no conflicts), you still need to do manual exploratory testing (no?) which, done well, should take some time.

These are the main benefits of CI, but there are others. Conway's Law often weighs heavily on my mind, and so when I am forming a team, with a shared goal, shared vision and shared purpose, I feel it is natural to extend that to shared code.

By no coincidence, these benefits I mentioned oppose the disadvantages that I see in BPF. As I said - I have only been able to decipher that you don't believe the process I described is true BPF, and that this post is a hack so I am running blind. I welcome the opportunity to understand the why's (not the how's) from your position.

Re: Experience Report: Branch by Feature

François Beausoleil — Thu, 14 Jul 2011 08:37:07 -0000

Since refactorings belong on master, when you find an opportunity, stash, switch to master, refactor, pull and push, switch back to the feature branch, pull master, pop your stash, then go on your merry way. I agree this isn't ideal: if the refactoring depends on code that's only in the branch then it's difficult to move the code to master.

I have succesfully done refactorings this way on one project, but to be frank, I would prefer feature toggles in the future, rather than branch per geature.

Re: Experience Report: Branch by Feature

Neale Upstone — Thu, 14 Jul 2011 08:35:17 -0000

Great article. The refactoring challenge is the one that interests me, and I'd be interested to hear a few more war stories on why refactoring on master is such a bad idea.

My personal view is that refactoring on a branch should be a last resort. I've seen developers attempt a refactor (in this case something not so massive, but a notable simplification, migrating from EJB2.1 to 3 - oh the joys of 'enterprise').

We were using Git, and yet the developer in question ended up with 200 un-committed changes after 3 days failing to move this technical story across.

We could suggest that he'd have felt safer to commit as he went along on a branch, but he was working on a branch: his local branch of master.

I picked it up and started from scratch, committing and pushing regularly, on master.

The approach here was first to refactor to isolate the area of change from other developers, testing and pushing as I went. Once I was happy, I created a new module with the EJB support and a few dependency changes to pick this for deployment.

The commit that made the switch live was 2 line which changed. One in each of 2 Maven POMs.

I think there are a number of ways to tackle refactoring on master, and I think modularity and encapsulation have a lot to offer that challenge, as helped above.

I'd love to hear some arguments against this... :)

Re: Experience Report: Branch by Feature

Simon Brunning — Thu, 14 Jul 2011 07:05:18 -0000

That's Brunning's First Law of Change Control, Tiest.

Brunning's general First Law states "No anecdote including the word "tequila" has a happy ending".

Re: Experience Report: Branch by Feature

Brian Guthrie — Thu, 14 Jul 2011 07:02:34 -0000

I thought the whole point of continuous integration is to prevent devs from playing in safe sandboxes. Didn't we decide a while back that independent sandboxes were a bad idea for precisely the reasons that Sarah has so kindly enumerated?

Re: Experience Report: Branch by Feature

Tiest Vilee — Sun, 10 Jul 2011 11:17:27 -0000

Brunning's Law[1] states: she who merges first, merges least.

While this may seem farcically obvious, the ramifications of this law are surprising. For one, if you want to minimise merge hell then you need to merge as often as possible. For another, getting your merge in seconds before your colleague always results in much hilarity :)

My experience also gels with yours - even with Git, I find that the extra pain that inevitably results from merging (see Brunning's Law) is very rarely worth it. I think that people who argue against toggles/abstraction 'branching' are doing so because they don't have the structures in place to make this easy. Maybe code should be both testable and toggle-able...

[1] That's Simon Brunning to you :)