| Time |
S |
Nick |
Message |
| 00:40 |
|
|
Naros joined ##javaee |
| 00:52 |
|
|
Naros joined ##javaee |
| 00:56 |
|
|
kobain joined ##javaee |
| 01:09 |
|
|
kobain_ joined ##javaee |
| 01:14 |
|
|
Naros joined ##javaee |
| 01:15 |
|
|
cem_ joined ##javaee |
| 01:15 |
|
|
Naros joined ##javaee |
| 01:15 |
|
cem_ |
hi |
| 01:16 |
|
|
kobain joined ##javaee |
| 01:21 |
|
pdurbin |
cem_: hi |
| 01:25 |
|
cem_ |
pdurbin: I feel some tut on java is not complete like io is there any tut u recommend ? |
| 01:26 |
|
pdurbin |
cem_: how about http://docs.oracle.com/javase/tutorial/ |
| 01:27 |
|
|
ho joined ##javaee |
| 01:27 |
|
cem_ |
Thanks .. I just looked into it just to confirm i asked |
| 01:28 |
|
pdurbin |
cem_: if you like the command line: https://github.com/pdurbin/maven-hello-world |
| 01:29 |
|
cem_ |
haha your the creator of this channel :D |
| 01:29 |
|
cem_ |
Thanks pdurbin i use terminal all the time |
| 01:31 |
|
pdurbin |
huh, neuro_sys is the founder, actually: http://irclog.greptilian.com/javaee/2013-07-17#i_10486 |
| 01:31 |
|
pdurbin |
yeah, and Sircle, whoever that is |
| 01:32 |
|
pdurbin |
per /msg ChanServ info ##javaee |
| 01:37 |
|
cem_ |
you have high rep in stackoverflow coooool |
| 01:39 |
|
cem_ |
i started to use postgres i guess java would support it |
| 01:43 |
|
pdurbin |
cem_: oh sure, our app uses postgres: https://github.com/IQSS/dvn/blob/develop/doc/sphinx/source/dataverse-developer-main.rst |
| 01:44 |
|
pdurbin |
and whartung is the one with high rep: http://irclog.greptilian.com/javaee/2013-10-08#i_28961 |
| 01:47 |
|
cem_ |
I too had once a notable question in stackoverflow but it was underrated :( |
| 01:49 |
|
pdurbin |
cem_: have a link? |
| 01:49 |
|
cem_ |
that could expose me :) |
| 01:49 |
|
pdurbin |
:) |
| 01:50 |
|
pdurbin |
we do log all the things. no pressure |
| 02:36 |
|
|
cem_ left ##javaee |
| 03:09 |
|
|
sfisque joined ##javaee |
| 06:11 |
|
|
dangertools joined ##javaee |
| 06:11 |
|
|
dangertools joined ##javaee |
| 06:18 |
|
|
Quest joined ##javaee |
| 06:30 |
|
|
sfisque joined ##javaee |
| 06:38 |
|
|
sfisque joined ##javaee |
| 09:35 |
|
|
Quest joined ##javaee |
| 10:46 |
|
|
Technodrome joined ##javaee |
| 11:20 |
|
|
MegaMatt joined ##javaee |
| 12:07 |
|
|
Technodrome joined ##javaee |
| 12:17 |
|
|
Technodrome joined ##javaee |
| 12:42 |
|
|
Guest13065 joined ##javaee |
| 12:44 |
|
|
shoky joined ##javaee |
| 13:10 |
|
|
kobain joined ##javaee |
| 13:44 |
|
|
Naros joined ##javaee |
| 16:21 |
|
|
shop_keeper joined ##javaee |
| 16:35 |
|
|
sfisque joined ##javaee |
| 16:56 |
|
sfisque |
i'd like to gather some thoughts on converting "tech debt" into "user stories". |
| 16:58 |
|
sfisque |
besides the "usual suspects" of "as a user i'd like to [perform an action] with the [expected outcome] what other constructs have people used to capture a "tech debt" ticket as an actionable "user story"? |
| 17:20 |
|
balazare |
sfisque: depends on the size of the technical debt. I have a range of items that we manage in different places: some small items are just tasks in JIRA, the more medium tasks are user stories (either spreadsheet or some text doc), the big items are highlevel plans at best. |
| 17:22 |
|
balazare |
sfisque: the medium to large things are also a lot more fluid - a fixed documentation structure may not apply at that point |
| 17:22 |
|
sfisque |
aye. the issue we're facing is that the corp has put pressure on us to go "full agile", which means all the developer effort has to be measurable in "value metrics". since tech debt generically has no "user facing story" we're in a situation that we have to "change the representation" so that it gives some "apparent user value". i know it's corp cruft, but i'm willing to go through the exercise of playing ball (to see if it |
| 17:24 |
|
sfisque |
hence my question. i'm curious if others have gone through a similar exercise successfully (or not) and gather some war stories to weigh while i perform my assigned groomings |
| 17:26 |
|
balazare |
sfisque: the problem I see is that the larger tech debt is only describable on a MRD/PRD level which can get hairy because it will be difficult to create a value proposition |
| 17:27 |
|
sfisque |
aye. let me give a concrete example. we have a number of JSF converters that "do bad things", and we have a jira task that says [paraphrased] "refactor the converters so they don't do bad things". |
| 17:28 |
|
sfisque |
i've wrestled the task into a user story that says "As a user, i want to solicit input via Pick Lists or Option selectors in an performant and referentially correct manner." but that still seems vague and has "definition of done" issues |
| 17:30 |
|
sfisque |
this is kind of a new realm for me, because all examples of agile i have been party too were the usual "hybrid" approach, and tech debt has always been "that red headed step child". i want to embrace fixing this, since i'm now in a context where the corp wants "real agile" rather than some bastard hybrid |
| 17:31 |
|
sfisque |
so i now solicit my fellow EE-heads and see if we can solve this in a tenable manner :-) |
| 17:32 |
|
balazare |
sfisque: the definition of doneness is critical, esp. when it is technical debt. Presumably there is an application that runs, but just not as good as it should |
| 17:34 |
|
balazare |
sfisque: there is also a trap here in that a shiny new agile process won't solve all of the issues just by magic. |
| 17:34 |
|
sfisque |
a tautological presumption. every app has inefficiencies |
| 17:34 |
|
pdurbin |
sfisque: here's some technical debt we have: https://redmine.hmdc.harvard.edu/issues/3225 |
| 17:34 |
|
sfisque |
agreed, but like i said, this is an area that has always "been swept under the rug" and i'm willing to "go through the motions" to see if it can be done "by the book" |
| 17:36 |
|
balazare |
sfisque: I think the important part is to have it sufficiently documented and make sure the tasks go through the same design refinement steps |
| 17:37 |
|
sfisque |
pdurbin: aye, that's pretty much what ours look like (or similarly) but that format falls outside of the "user value" context. again, i'm not arguing the validity of the ticket, just that we are tasked with "re-representing" our TD as actionable user stories so that we're lock step. i'm willing to accept (after the work is done) that it might be square peg/roudn hole, but i'm interested to see if it can be done properly firs |
| 17:37 |
|
sfisque |
aye bala |
| 17:37 |
|
balazare |
sfisque: it is way too easy to sweep it aside because it is presumed old tech debt or well understood |
| 17:38 |
|
sfisque |
refinement: i meant "swept aside" not in the "it doesnt get done" but rather "we'll just do it as part of dev, but it does not get dealt with according to 'proper agile' process. am i being clear? |
| 17:39 |
|
balazare |
sfisque: you are clear, that is exactly the problem |
| 17:39 |
|
sfisque |
corp is on board with addressing TD, they just want it to fall into the metrics of the "other normal stuff" rather than an intangible with unmeasurable ROI |
| 17:40 |
|
sfisque |
so back to my example, does anyone have any thoughts on the goodness (or crappyness) of my recapturing that specific TD as a user story. feedback? |
| 17:41 |
|
sfisque |
it's kind of wierd to be in this situation, having to shuffle off the kruft of "doing it half assed" for a decade and trying to "do it right" |
| 17:41 |
|
sfisque |
i feel like a newbie :P |
| 17:43 |
|
sfisque |
i feel the story is actionable, but it does not directly translate into a "done criteria". which kind of bothers me, but that can be fine, if that results from grooming in logical/physical zoning |
| 17:43 |
|
balazare |
sfisque: can you tie to a bug? or a performance? |
| 17:44 |
|
balazare |
sfisque: user experience is a pretty good leverage, but also subjective |
| 17:45 |
|
sfisque |
well, it has several aspects. some cause performance issues. some are "latent bugs" where under certain data constraints, we can report the wrong piece of data (not using the PK in the converter conversation) |
| 17:47 |
|
sfisque |
so i guess it can become several user stories. i guess that's part of the problem. it's too encompassing (the bug is targetting the construct as a whole) rather than specific failure points |
| 17:48 |
|
sfisque |
that was a good observation balazare. TY |
| 17:51 |
|
sfisque |
so now i have at least two stories: As a user, i want Pick Lists and Option selectors to be populated in an performant manner. |
| 17:51 |
|
sfisque |
As a user, i want Pick Lists and Option selectors to be referentially correct in soliciting my responses. |
| 17:53 |
|
sfisque |
so now the acceptance criteria can be specified specifcally (1) do the lists appear "fast enough [ based on page load/refresh requirements], and (2) do all my solicitations result in correct data persisting in the db tables. |
| 17:55 |
|
balazare |
sfisque: as far as I can see you have two different issues: one is the spec itself (user stories and what not) and the other is how to the sell it to the project management |
| 17:55 |
|
sfisque |
it's farther out than that. SM is on board. its more about the product owner |
| 17:56 |
|
sfisque |
SM = scrum master (they're kind of phasing out PMs in favor of SM/COPM) |
| 17:57 |
|
sfisque |
COPM = community of practice master (agent, whatever) |
| 17:58 |
|
sfisque |
well, gotta pack up for a bit. TY pd and bala for your feedback |
| 17:58 |
|
pdurbin |
sfisque: code strong |
| 17:58 |
|
sfisque |
:-) |
| 17:58 |
|
balazare |
sfisque: np - see ya |
| 17:58 |
|
balazare |
pdurbin: :) I like that! |
| 18:01 |
|
pdurbin |
balazare: it's his catch phrase :) |
| 18:15 |
|
|
kobain joined ##javaee |
| 18:54 |
|
|
Technodrome joined ##javaee |
| 19:26 |
|
|
Technodrome joined ##javaee |
| 19:44 |
|
|
Technodrome joined ##javaee |
| 19:45 |
|
|
kobain joined ##javaee |
| 19:46 |
|
|
sfisque joined ##javaee |
| 19:47 |
|
|
sfisque1 joined ##javaee |
| 19:53 |
|
|
Technodrome joined ##javaee |
| 20:00 |
|
|
Technodrome joined ##javaee |
| 20:16 |
|
|
Naros left ##javaee |
| 20:39 |
|
|
Technodrome joined ##javaee |
| 20:47 |
|
|
Technodrome joined ##javaee |
| 20:55 |
|
|
Technodrome joined ##javaee |
| 21:09 |
|
|
Technodrome joined ##javaee |
| 21:12 |
|
|
sess joined ##javaee |
| 21:25 |
|
|
SoniEx joined ##javaee |
| 21:27 |
|
|
Technodrome joined ##javaee |
| 21:36 |
|
|
Technodrome joined ##javaee |
| 23:32 |
|
pdurbin |
sfisque1: so you put these user stories in jira? |
| 23:35 |
|
sfisque1 |
unclear yet. some of us want to. some are suggesting different tools |
| 23:36 |
|
sfisque1 |
for now, i built a wiki page that broke the original ticket into 13 user stories. the page links back to the original ticket |
| 23:37 |
|
pdurbin |
ok. I'm interested in the user story concept, but I don't have any experience with it |
| 23:37 |
|
pdurbin |
I mean, I've heard people talk about it, but that's it |
| 23:40 |
|
sfisque1 |
basically it moves the emphasis from systemic requirements to a more visible paradigm that maps to the various other concepts ( the Actor [performs action] [with expected results] model maps well to UML actor graphs) |
| 23:41 |
|
pdurbin |
not like akka actors, though |
| 23:41 |
|
sfisque1 |
not sure that was clear english. my brain is a bit fried. had to work on several escalations at the same time as trying to wrap my brain around this shift |
| 23:41 |
|
sfisque1 |
akka? |
| 23:41 |
|
* pdurbin |
looks at http://doc.akka.io/docs/akka/2.0/scala/actors.html |
| 23:42 |
|
sfisque1 |
not sure. i know NULL about scala |
| 23:42 |
|
sfisque1 |
if it maps to the UML concept of actors, then yes. otherwise, too low level |
| 23:42 |
|
sfisque1 |
actors in agile are very similar to OMG/UML actors |
| 23:43 |
|
pdurbin |
OMG != ZOMG I bet |
| 23:44 |
|
sfisque1 |
yah. lets see if we get lucky |
| 23:44 |
|
sfisque1 |
javaeebot lucky OMG UML modelling |
| 23:44 |
|
javaeebot |
sfisque1: http://www.uml.org/ |
| 23:46 |
|
whartung |
a user story is "As a Game Player, I was to hit a Smart Bomb and blow everything up on the screen." |
| 23:46 |
|
sfisque |
aye |
| 23:46 |
|
sfisque |
good example |
| 23:46 |
|
whartung |
for some reason, people have to write entire books describing this concept -- I'm at a loss as to why. |
| 23:46 |
|
sfisque |
there are many ways to "do it wrong" |
| 23:47 |
|
whartung |
I am a stickler for formal http://c2.com/cgi/wiki?GalacticModelingLanguage however... |
| 23:47 |
|
sfisque |
it's definitely part "art" and part "science" |
| 23:47 |
|
sfisque |
but once you "get it", you're solid |
| 23:48 |
|
sfisque |
lol GML++ |
| 23:48 |
|
sfisque |
i prefer GML# |
| 23:48 |
|
sfisque |
:P |
| 23:48 |
|
sfisque |
but that has M$ only extensions |
| 23:48 |
|
whartung |
:) |
| 23:49 |
|
sfisque |
box, line, label, paper_clip |
| 23:50 |
|
whartung |
this thing, also, is awesome. |
| 23:50 |
|
whartung |
http://www.websequencediagrams.com/ |
| 23:51 |
|
sfisque |
lol, napkin style |
| 23:52 |
|
whartung |
yea |
| 23:52 |
|
sfisque |
i want "matchbook cover style" |
| 23:52 |
|
sfisque |
or "grain of rice" style |
| 23:52 |
|
sfisque |
>.< |
| 23:54 |
|
whartung |
http://upload.wikimedia.org/wikipedia/en/6/65/Aidrawme.jpg |
| 23:56 |
|
sfisque |
poker vote: 3 |
| 23:56 |
|
whartung |
I don't know what that means |
| 23:57 |
|
sfisque |
you presented a "user story" on the matchbook. now we vote on "how big the story is for work load". i vote 3 |
| 23:57 |
|
sfisque |
:-) |
| 23:57 |
|
whartung |
oh, yea we don't do points here |
| 23:57 |
|
whartung |
we just summarily dump them in the back log lol |
| 23:57 |
|
sfisque |
As a clown, i want to be able to lift open |
| 23:58 |
|
sfisque |
….. see inside |
| 23:58 |
|
sfisque |
*** to see inside |
