-1

I like to try out stuff in projects I am in.

When something doesn't seem right to me, I like to implement a new thing, see if it fits or not for a while, and then, slowly implement it to the rest of the cases.

For example - Lets say that in the UI, I want to try out unidirectional flow. So I take one page, and make it unidirectional.

Once I see it works well, I apply to another page, and another, until it is in all the pages.

However, a lot of times I run into teams that have a mind-set of 'all or nothing'. Meaning - if you want unidirectional flow, implement it to all the pages. Sometimes this requires a debate to convince the change is needed first because it is a lot of effort.

This mentality seems to me as creating an environment where introducing a change is impossible. Which beyond project implications might also have a motivational effect on the team itself.

When should a team undeniably prefer to introduce a change in a growing manner instead of a complete refactor of the code? Or is it always debatable?

  • 1
    There may not be a succient way to answer this question. Different people within the same team will have different opinions on where this line is and how much effort should be spent on it. I tend to be against big project-remaking refactorings unless there is an obvious problem, because refactorings themselves can lead to new bugs. – Mark Rogers Sep 27 '17 at 18:28
  • 3
    I'm not exactly sure why you conflate delivering a feature with a "complete refactoring". Refactoring doesn't have much to do with implementing a feature. Then, there's a question of who asked you to do this change. It seems weird to get to the point where you need to deliver the feature to know if it is feasible or not. – Vincent Savard Sep 27 '17 at 18:29
3

Consistent UI is very important. That's why most, if not all, shops have a "standard" way of doing UI things, even if that standard is de-facto. Often, that standard arises from conventions that users already understand because they are widely used.

Introducing new UI innovations into an application where they didn't exist before can confusing, both to the user who has to figure out how your new gadget works, and the developers who wonder why you're not conforming to the application's gestalt and who now have to maintain two different ways of doing things.

Accordingly, any UI change that departs substantially from the standard should go through several phases to determine its efficacy:

  1. An experimental phase, where new UI innovations are explored,
  2. A dogfooding phase, where new UI innovations are tested in-house, to see if they hold up,
  3. A vetting phase, where innovations get pushed out to the user community on a beta basis and feedback is gathered,
  4. An integration phase, where the innovation is applied to all areas of the application where it is applicable, useful and promotes uniformity,
  5. A rollout phase, where the new innovation is pushed to the user community in a new software version.

Doing it this way requires a lot of work, and comes with a degree of inertia. It should. UI changes are different from changes to the program's functionality. Facebook gets an earful from its user community for every change it makes to its UI, no matter how minor. Nobody complains about a change they cannot see.

If you violate the shop's prime directives with respect to internal architecture, you only affect the other developers. But UI, in a very real sense, is the "face" of your company. Changing that face requires more than just one person's arbitrary decision-making.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.