Junilu Lacar

Sheriff
+ Follow
since Feb 26, 2001
Junilu likes ...
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
Columbus OH
Cows and Likes
Cows
Total received
197
In last 30 days
1
Total given
70
Likes
Total received
1678
Received in last 30 days
33
Total given
310
Given in last 30 days
7
Forums and Threads
Scavenger Hunt
expand Rancher Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Junilu Lacar

Satyaprakash Joshii wrote:For every sprint the pattern is such that we are asked to add more user stories then we estimate for and at the end of sprint in reports whatever is not completed comes in Red.I want to know that if  this keeps repeating for many months what would be the result of this?



If I were in that situation, the immediate result would be me polishing up my resume and getting the heck out of there as soon as I can. If I had money socked away so that I could survive until my next job came along, I would be out the door immediately.

If you are unfortunately unable to extricate yourself from a toxic environment like that, the result would be declining morale in the development team, declining productivity, increasing number of bugs, more pressure from management to get things done, and an ever increasing downward spiral into the pits of hell. That's what you have to look forward to in the next few months unless somebody stands up and says "Enough of this madness! This isn't what Agile is supposed to be!"
12 hours ago
Late to the party but what OP describes is exactly why Agile these days isn't what it was intended to be and enthusiasm for it is dying in many places (some even consider it to be Dead already). No matter what you choose to call it, I certainly wouldn't call it "Agile", that way of working is just not what the originators of the Manifesto envisioned. That's what they were trying to get away from.
14 hours ago
I have had a bit of time to catch up on my reading list so here's a word cloud that's kind of floating around in my head right now:

communication Collaboration Working Software building the right thing Outcomes vs Output
testing experimentation data Design Thinking #noProjects Teams #noEstimates



I don't know why but Josh's idea seems to fit in there somewhere.

Edit: Maybe because #noPO? And Chartering?

Joshua Kerievsky wrote:... you have replaced product owners with communities that collectively own the work


Jeanne Boyarsky wrote:Making all decisions by committee feels incredibly time consuming given the number of competing demands we have.


I think there's an important distinction between committee and community. I think having a charter that everyone involved buys into is a key differentiator.
It kind of reminds me of Conway's Law and Reverse Conway's Law. I think if you are seeing problems in your architecture and design, definitely go back to Conways' Law and see how your design problems/flaws are influenced by your team's structure and communication mechanisms. The influence is also there in reverse: changes to your design and architecture also influences your team structure and communication.

If things are working for you the way they are, you probably should just go with it. Don't fix it if it ain't broke. If you think it might improve things for your team or give you significant gains, then it is certainly something you could try. Just remember there's a balance. If you eliminate something that you found useful before, something else has to fill the void to provide that same usefulness or add to what you had before.
I read that article a couple of weeks ago. Let's unpack some of the ideas from article.

Regarding prioritization, he writes:

Joshua Kerievsky wrote:Product management has a voice in this community, but they don’t “own” prioritization or planning. Developers and testers and UX people also have a voice in planning and prioritization.


The idea of a charter and chartering is central:

If you observe a team that shares ownership of planning and prioritization, you’ll be delighted to see that everyone is continuously paying attention to and discussing what is most important to do and how to spend the time wisely. Without chartering, this work can get messy. Chartering is crucial to eliminating a product owner role. Yet chartering isn’t a silver bullet. Good risk management is always essential. The team must go after the highest value work, while managing the key risks.


In the closing paragraph:

...what I’ve described here is exactly how their PO functions. In that case, I would say that “Product Owner” is no longer their role. When a team works together to achieve an important outcome, they co-own the work. When that happens, you have replaced product owners with communities that collectively own the work of achieving inspiring outcomes. I find that is far superior to having a Product Owner.



I haven't seen this first-hand so I can't really speak to whether it works in practice or not. Seems like it might be worth experimenting with though.
That solution wouldn't be my choice. The semantics are still vague and the story that method call tries to tells seems awkward to me.

1. An "offset" is relative to some baseline. The call does not make it clear what is that baseline.

2. The "withOffset" part of the method name strongly suggests a desire for something to be expressed as a parameter instead. It's like the code really wants to be written like this:



If good names are used, the kind of API makes the code very explicit. The API you have chosen to go with is not as expressive.

3. Using a static method also does not help to clarify the context for the reader and it raises more questions for me as to the overall fitness of the design you've settled on. Why would the method be attached to the class, assuming this was in some kind of MyCalendar class, instead of an instance of the class? Seems to me like that's not the best choice to make.

Draque Thompson wrote:... sometimes I deal with bug that I have a lot of trouble reproducing. Being able to tell users to flip on a special logging mode, then having them send me the log after ... would be super helpful.


If I were one of your users, I'd probably hate you for making me do all that. At the very least, I'd be annoyed. Switching to a special mode is fine but "having them send me the log" seems like way too much work to burden the user with.

Surely, you can find some way to make the application notify you that something went wrong, without the user having to act as a middle man. At most, as a user I'd expect to see some kind of notification window that tells me something went wrong and gives me a few options, like to either Report the error, Ignore it, or Retry the action. That's about as much work I want to do to help you figure out what you messed up. See a message, decide on an action, then click a button to quickly hand off the problem to you, the developer/support team.
1 day ago
In keeping with the theme and style of the book, I might suggest this: Save yourself minutes of precious development time by writing short, vague, and generic commit comments. Who cares if people have to use diff to figure out what you did, right? Combine that with infrequent commits of large batches of code, the time you save adds up. Of course, you're going to waste everybody else's time but hey, that's life as a programmer, right?
1 day ago
FWIW, I really like that answer, Karl.

Do you have any advice in the book that's distinct from any of the things about inheritance that Josh Bloch goes over in his Effective Java Programming book?
1 day ago

Al Davis wrote:Many multiclass programs make use of the same variables in multiple classes; e.g. length and height in various geometric structures.  In general, there are 3 ways to make "copies" of the variables - pass them as parameters, obtain them via getX() methods, and (re)declare them within each class.  I can think of examples where one way has a clear advantage, and examples where I see no clear advantage.  Is there a widely accepted rule of thumb about this?

... Any advice?



Advice: If you want clear and specific answers, ask clear and specific questions.

Instead of saying "I can think of examples..." and then not giving one, you can give at least one specific example so that people don't have to guess what you have in mind. People, especially programmers in particular like many of us are, are not very good at mind reading. In fact, we suck as mind readers, so try to give as much context to your question as you can to keep people from making their own assumptions.

If there's a widely accepted rule of thumb that comes to mind from what you said, it's this: Do what makes sense. If that answer is too vague, that's only because I don't want to make any assumptions about what you had in mind when you framed your vague question.

1 day ago
it's important to understand the reason for that rule, which applies to all C-like languages that use braces to delimit code blocks. It's because unlike a language like Python, which uses indentation to group statements together into code blocks, you can inadvertently create a bug around an if statement that contains only one statement in its body.

Consider this code, for example:

The indentation clearly shows that the author's intent is to reset x to 0 only when it exceeds the value of LIMIT. However, line 3 will always be executed, regardless of the condition. This is a bug that can be difficult to find.

This kind of thing can happen if the code originally only had lines 1 and 2 and the programmer didn't bother to type in the optional braces because the body of the if-statement has just a single line to print out a message. Then maybe a few weeks or months later, another programmer comes in and wants to make a modification that requires the addition of line 3. If braces are not added to group together lines 2 and 3 as a code block that makes up the if statement's body, then you get a bug.
1 day ago
Refer to https://github.com/alibaba/Alibaba-Java-Coding-Guidelines for details.

When given a "rule" like "Write fewer lines of code," try to discover the context around it. For me, it's really about simplicity. Simple code is composed and adheres to Single Level of Abstraction Principle (SLAP) Simple code is cohesive and is focused on doing one thing and doing it well. To write cohesive code, you need to keep different concerns separate. The combination of the goals of having cohesive, simple, composed methods that are at the same level of abstraction often results in code that is short and sweet and coherent (that is, says and does one thing and does it well). So, rather than focusing on the number of lines, focus on cohesiveness, coherence, composition, and single level of abstraction. Writing code that has these qualities usually leads you to smaller methods. I have heard it said that Kent Beck's coding style is so eXtreme that he has many one-line methods whose names clearly reveal their intent and abstract away the nitty-gritty implementation details. He says he wants his code to tell the reader a story and that's how he does it, by extracting and abstracting to the extreme.
2 days ago

tangara goh wrote:The subjects and Ids will never change.


I'm not convinced that's entirely true. Subjects being taught in schools come and go all the time. There are new subjects that are offered, some become obsolete and are eliminated from the curriculum, others are renamed, etc. While those kind of changes may not happen every day, they do occur or have the potential to occur at the start of every term. The question really is whether or not you have to change your code at all if one or more subjects get added, modified, or removed. I would still argue that Enums are not the appropriate way to represent this idea.
2 days ago

Giovanni Montano wrote:so I want one class that does one thing, so want to get rid of the calendar business logic away from the view, and building a class `MyCalendar` looks nice to me as you suggest.As consequence I do not need to copy the event but just pass a reference to make my view class semantically clearer because more short and with one only responsibility, namely showing the user interface (1).

So I am going to build a class `MyCalendar` with all the needed android imports
and this class will have a method called insert( Event event, LocalDataTime moment){} (2)


The statement marked (1) is contradictory to (2) -- If the responsibility is to simply show the user interface, then why do you have method that changes the internal state of the Calendar? Managing state seems like it's the responsibility of a Model layer class, not a View/Presentation layer class. The view/presentation simply handles the visual representation of the model.  I would imagine you'd have at least two classes: Calendar and CalendarView.