13

On a SCRUM meeting the product team was debating about a feature on an API that will be consumed by mobile app. We had a mock up that showed how the screen should look like and what key elements it should contain (a "layout").

Based on this and the discussion I had with the product owner I created a prototype for an API response (HAL+JSON). It was very simple, HAL-compliant JSON that did nothing more than represent the things that were on the mockups. I did not get influenced by the future ideas that were foreseen by business people as they have tendency to change their ideas often and I decided to take the minimalistic approach. My proposal was rejected by the team and I've been outvoted 7 to 1.

The team decided to use more complex, non-semantic abstract json structure, that allows for more flexibility in arranging of the layout. The downside of that approach is we ended up with a set of uniform objects that may have null and empty properties by design. They also thought it would be nice to make A/B testing possible, yet it was based on their predictions only as we had no such requirement.

Most of the time we were debating about things that were not a part of the sprint nor mentioned on the mockups. The described problems were "what if marketing in the future will ...", "what if the business might want us to ...".

I and the product owner are experienced programmers and we've seen these kind of problems in the past. We try to follow the YAGNI and KISS principles. The rest of the team is a bit less experienced and although they know these principles, they seem not to understand them.

We agreed on their solution as the team as a whole is more important for us and we did not want to fight over something that is not that important. But I'm afraid if such thing can become a precedent for upcomming, more complicated debates? How to deal with such behaviour? Is there anything that I, as a team leader, can do better?

It's worth to mention that the product is an early-stage MVP.

Jacek Kobus
  • 321
  • 1
  • 10
  • 11
    `I'm afraid if such thing can become a precedence for upcoming, more complicated debates?` -- That also violates YAGNI: worrying about a future that might not happen. If you were going to stand your ground, you should have already done so. – Robert Harvey Feb 06 '17 at 19:51
  • @gnat: This doesn't appear to be about time constraints. – Robert Harvey Feb 06 '17 at 19:52
  • Is being HAL-Compliant not subject to YAGNI? – Matthew Feb 06 '17 at 19:54
  • @Matthew the whole thing took one week and I also prepared another prototype using plain JSON just to get rid of HAL, but it was also rejected seen as "not flexible enough". The team modified it and that modified version was finally used. The HAL works for us as a standard, a set of guidelines, and it is easier for me to enforce uniform structure on all endpoints. Previous API was not using any standards and it did not end well. – Jacek Kobus Feb 06 '17 at 20:02
  • 5
    Flexibility adds complexity. As long of the team understands that, one can move forward. – Jon Raynor Feb 06 '17 at 21:28
  • @jkobus is it because they simply don't understand the benefits of using HAL? It's not immediately obvious what the benefits are and HAL seems like a PITA at first. Perhaps you need to do a better job of explaining why you wanted to take that approach. – RubberDuck Feb 07 '17 at 10:54
  • @RobertHarvey: so no one should ask questions here if he just wants to improve his software engineering skills for the future instead of solving a problem at hand? I understand your point, but nevertheless it looks like a very extreme interpretation of YAGNI to me. – Doc Brown Feb 07 '17 at 11:08
  • @RubberDuck we are still using HAL but rather than using embedded resources it's a POJO, so its not that bad. It needs more documentation as it's not very self describing. The team agreed on using HAL in the beginning (it was chosen among few others). – Jacek Kobus Feb 07 '17 at 12:03
  • Well, that's a small win @jkobus. Take them as you can and keep lifting your less experienced team mates up. They'll come around. – RubberDuck Feb 07 '17 at 12:05
  • YAGNI is over-rated, just as DRY is over-rated. Foresight is valuable. The question is not "are we sure we will need this" but what's the likely ROI on investing the extra time. What are the costs of the extra complexity? These are very subjective calls but they are estimable and yet are routinely under-analyzed in the industry. I've rarely seen attempts to quantify these planning decisions. in past jobs, they've been routinely decided almost on a whim, yet they often have long term architectural implications to the bottom line. – Bradley Thomas Feb 07 '17 at 14:37
  • @DocBrown: Who said that? I certainly didn't say that. But if you're going to live by the sword, you might as well die by the sword. – Robert Harvey Feb 07 '17 at 16:18
  • @RobertHarvey: maybe I misunderstood you ;-) But for me it looked like in your initial comment you were questioning the OP, why he asks his question here, because his motives are driven by the wish of taking some precaution for the future. – Doc Brown Feb 07 '17 at 17:17
  • @DocBrown: Oh, no. The question has a close vote (Too Broad), but it's not mine. – Robert Harvey Feb 07 '17 at 17:44
  • Question for you: How difficult/long is your solution? How difficult/long is the team's suggested solution? Now, if you have to do rework later, following your design, how significant would it be to enhance it? How does that compare to what the team suggested? Finally, the Product Owner usually can provide some insight into potential future features that might guide the decision. – Curtis Reed Mar 22 '17 at 23:48

8 Answers8

10

I feel your pain, have been there. IMHO these kind of problems are caused by the fact you have a team of 8 persons, which is already too big to let you always come to the best strategic decisions.

In a team of size of 8 or more chances are high the number of mediocre programmers is higher than the number of experienced ones. That will often lead to situations where the better decisions are outvoted by mediocre ones. That does not sound satisfactory, especially when you are (or think you are) one of the more experienced guys, but at least the same is often true for really bad decisions.

Fact is, there is not much you can do about it as long as the team does not change, at least if things shall stay democratic, so either

  • learn to live with it
  • work with the team for one or two years, share your own expertise and hope they learn the value of YAGNI and KISS over time
  • work on your own skills of "selling" design or strategic decisions to the team
  • try to switch to a different (maybe smaller) team where your own level of expertise is nearer to the average of the whole team

I think the only way to learn and understand the real value of a minimalistic approach and YAGNI is by making some experiences first hand. For example, by getting involved in maintainance of a legacy system with a lot of wrong "what if" predictions, wrong design decisions motivated by "just in case" arguments, or containing lots of overgeneralized framework code which was actually never needed. But that is nothing you can teach your team members in two days, some experiences people have to make by themselves.

Doc Brown
  • 199,015
  • 33
  • 367
  • 565
  • 5
    Most people have to touch the stove to learn it's hot and not to touch it. Software is much the same. ++ – RubberDuck Feb 07 '17 at 10:58
  • 2
    Keeping a project log/diary is key for this sort of thing. Once you have recorded the various discussions that have taken place, they are far more concrete that people's recollections of conversations months or years later. There is a good question on the practice [here](http://softwareengineering.stackexchange.com/questions/137686/how-useful-is-a-project-log-or-diary). – Robbie Dee Feb 07 '17 at 11:41
  • @RobbieDee: sure, if it helps the team to learn about YAGNI and KISS. – Doc Brown Feb 07 '17 at 11:48
  • 3
    The 3rd bullet (working on your own skills in "selling" a design) doesn't get enough attention. It's why developers still need to have (or work on) good communication skills. – Syntax Junkie Feb 07 '17 at 18:40
  • @RandallStewart: absolutely. But even with the best communication skills it can be hard to sell YAGNI to people who have not made some experiences by themselves, or confuse it with "quick and dirty", or were educated that "abstraction is (always) good" and so try to abstract things for the sake of abstraction instead for the sake of simplification. Communication needs two sides - one who can explain things well, and one who is willing to listen and understand. – Doc Brown Feb 08 '17 at 06:06
  • @Doc Brown: I should have clarified that good communications skills doesn't get enough attention by the programming industry as a whole. You gave it appropriate attention. I was pleased just to see the topic listed in your reply. (I also see your point that "communication" skills needs to include the different aspects of receptiveness.) – Syntax Junkie Feb 08 '17 at 12:56
  • As I wrote in other comment - the team did what it was supposed to do - they solved the problem. It was my and product owner's mistake, that the matter was too broad and poorly described from the beginning. As @john-wu wrote in his answer, it's also important to specify clear acceptance criteria. Thanks guys. – Jacek Kobus Feb 13 '17 at 16:32
8

Forward compatibility is a legitimate concern

If one of the seven developers who outvoted you is the architect, it is his right to introduce NFRs as needed, and one of those NFRs could be "forward compatibility," especially when you are supporting a remote system component that might have a more sparse release schedule. You don't want users to have to install a new version of an app because you didn't think ahead.

Like other requirements, you need acceptance criteria

That being said, any NFRs must be documented as requirements and must have defined acceptance criteria. Also, you must come up with a means of testing them. That is why YAGNI is important-- you don't want to write code that can't be tested, and if the only purpose of the code is to support a feature that nobody is using, it is difficult to test.

It shouldn't be a judgment call

I would suggest you get the team to agree on the unspoken requirement that you apparently missed and get it written down. Once you have defined a means of testing it, your implementation should fail at least one test and therefore it shouldn't be a matter of voting.

John Wu
  • 26,032
  • 10
  • 63
  • 84
  • 1
    Where in the question do you read that the OP's team left the path of YAGNI because of a forward compatibility requirement? – Doc Brown Feb 07 '17 at 06:37
  • Forward compatibility is what the `Content-Type` header is for – Jack Feb 07 '17 at 07:38
  • 2
    I am willing to call it something else if you want, maybe extensibility. The point is the same; it is still an NFR. – John Wu Feb 07 '17 at 09:15
  • 1
    There are two ways to make a system extensible. Way one is trying to foresee lots of potential requirements changes and make things heavily configurable "just in case". I am sure one can invent lots of acceptance tests for this kind of extensibility. Or, keeping things as simple as possible, so the code base stays small, easy to grasp, and extension points or abstractions can be added later when they are really needed. The latter is nothing you can (or need to) write tests for. Thus I don't think this can be solved easily by "writing unspoken NFRs down"... – Doc Brown Feb 07 '17 at 10:07
  • ... so this is more about how to hold a team of maybe creative developers back from making assumptions about NFRs and invent some. – Doc Brown Feb 07 '17 at 10:09
  • @John Wu I totally support you on "forward compatibiltiy" or however we will call "easy extendibility in the future". This is related to the "Open-Closed-Principle" that forces to think us about suitable abstractions at the systems borders. Omitting them is careless. – oopexpert Feb 07 '17 at 13:02
3

It sounds like your development team is trying to facilitate the product team by creating a framework that allows them to do quick trials, which is apparently what the product team would really love to have. Your approach is more like "literally give them what they ask for and don't think for them".

If I were the product owner I bet I would be a lot happier with a development team taking the first approach than the latter.

Martin Maat
  • 18,218
  • 3
  • 30
  • 57
  • 3
    +1 anticipating and planing for change is not the same thing as going full architecture astronaut and creating an [inner platform](https://en.wikipedia.org/wiki/Inner-platform_effect). A bit of groundwork right now can prevent a lot of work in the future. While OP's team is perhaps leaning a bit too much into the direction of hypotheticals, a fundamentalist YAGNI approach is certainly suboptimal. – amon Feb 06 '17 at 20:22
  • 4
    It sounds more you would happily outvote the OP and make the same mistakes of planning for *"what if marketing in the future will.."* than the rest of the team. When people start building frameworks instead of application software when the task is to build application software, they are almost always doing it wrong. – Doc Brown Feb 06 '17 at 21:41
  • @DocBrown Technically I would agree. This case however seems to be about willingness to facilitate versus demanding personal respect. Being "right" on the one hand versus being useful or helpful on the other hand. What I read between the lines is that the OP is losing ground and chooses to pump up his ego by underscoring his experience to an online audience instead of contributing in an environment he does not feel comfortable in anymore. This dynamic is typical to the introduction of scrum. – Martin Maat Feb 07 '17 at 07:02
  • @MartinMaat I was a bit disappointed by the fact that they disagreed with me. I did not understand why it happened. During everyday work I help them with code reviews etc. We often argue but I like it, because the final result is better; I know that they respect my opinion; I always try to use valid arguments that support my theories. In the end they choose the best option and also take responsibility for it. The team did what it was supposed to do - they solved the problem. It was my and product owner's mistake, that the matter was too broad and poorly described from the beginning. – Jacek Kobus Feb 07 '17 at 21:50
2

Well, my opinion is democracy isn't working properly - neither in political system, nor in a team where most programmers are junior or mediocre.

Your word, as a team leader, and one of most experienced people in a team, should have higher impact then the rest of the team. If YAGNI is important for you, then you should make a presentation about it. Discuss about it, and show them why is it good.

After all, your responsibility is higher then for other people. It is not only to write code, but also to guide people.

Robbie Dee
  • 9,717
  • 2
  • 23
  • 53
BЈовић
  • 13,981
  • 8
  • 61
  • 81
  • 3
    Democracy is probably the cause of the problem here, but not being democratic is IMHO no solution, because it can easily introduce bigger problems than the ones described in the question - it can actually ruin the team. – Doc Brown Feb 07 '17 at 08:41
  • @DocBrown You just contradicted yourself in the same sentence. IMO some decisions are not up to people to decide. What OP explained is one of them. To quote Armstrong for people not using YAGNI: [You wanted a banana but what you got was a gorilla holding the banana and the entire jungle](https://www.johndcook.com/blog/2011/07/19/you-wanted-banana/) – BЈовић Feb 07 '17 at 08:57
  • 2
    No, this is not a contradiction (maybe I did not express my point well). Things are just not always "black and white". Just because democracy does not work well in some situations, being not democratic is not a guarantee for improving the situation and making things better. It is often not that simple. – Doc Brown Feb 07 '17 at 09:45
  • 1
    With democracy you do not neccessarily get the "right" thing you get the thing most of the persons aggree on. And this can be flawed. And often the "right" thing has a problem with social acceptance. YAGNI should not be handcuffs that will hinder you to introduce proper abstractions that will enable you to easily add the "gorilla" or the "entire jungle" if needed. – oopexpert Feb 07 '17 at 12:57
  • @oopexpert The problem is: you **may** need them. YAGNI talks against over engineering. Proper abstractions are one thing, adding stuff that you may not need are different matters. – BЈовић Feb 13 '17 at 07:23
2

It think there is a little confusion about YAGNI.

Developers often think they follow YAGNI when they omit abstractions that will keep the system "closed for modification and open for extension".

Unless you do not "extend" the system with an "obviously" not requested functionality you do not deal with YAGNI. Introducing abstractions where extending might occur is the already mentioned "forward compatibility".

My personal opinion is that only a profound knowledge of the domain will help to make decisions of abstraction and where to locate it.

oopexpert
  • 769
  • 4
  • 7
2

The trouble with YAGNI AND KISS is that they are completely subjective and vague.

json?? YAGNI! just send a csv string!

objects?? KISSTUPID!!! just use gotos!!

The 'Team Leader' role isn't well defined, but I would suggest that you distance yourself from expressing subjective opinions on your teams technical choices. Even if you feel they are wrong. Stick to a short list of well defined requirements.

  • unit tests for code
  • integration tests for apis
  • automated UI tests for the end product
  • performance and scaling requirements

if the team can achieve passing tests for all the business requirements and basic performance at scale technical requirements you have a working product.

After that its just pushing to do the same but faster

Ewan
  • 70,664
  • 5
  • 76
  • 161
1

Everybody in the team must agree on the definition of done. Without this, you're prone to massive amounts of scope creep, points of view and bastardisation of the core requirements.

Anything delivered over and above this must be on the backlog which will itself also have its own definition of done.

As for priorities, the MoSCoW method has always served us well - YMMV.

Robbie Dee
  • 9,717
  • 2
  • 23
  • 53
1

My first thought about this is...Why is the team concerned about changes? Do they have some historic understanding of the Product Owner that makes them feel like they need to build the first solution to be a bit more configurable to make future enhancements easier? If your solution would take 2 days, and theirs 5 days, yes, it's over twice as long. But if alteration of your plan would take 2 days each time, but an enhancement to their would take 1 day, their plan does seem more efficient over the long haul. I don't think there is a RIGHT or WRONG decision in this question. It depends on other factors, IMHO. However, you are RIGHT about this mindset if on other solutions they double the LOE without any direct guidance to do that (some evidence that the additional complexity is required for scalability, robustness etc). My suggestion would be to bring the product owner into these conversations, because they need to help with prioritization. If your solution is 5 points, and it would meet the need now, but what they want to do would require 50 points and two sprints or more, the PO may say "hold on, we have a high priority release of this MVP planned and can't spend 2 weeks building out functionality that isn't on the roadmap!"

Curtis Reed
  • 153
  • 7