Related
as COVID put us in a new situation, where everybody is at home we are still struggling with how to do our SCRUM dailies well.
One of the biggest challenges is, that wo do not have a chance to use our JIRA-board as we would do offline. What we usually do now, is that use a video-conferencing-tool (such as Slack, Zoom, Teams) and then somebody starts to share his screen.
But this means, that only this person has control over the screen and can perform any actions on the JIRA board, but now the whole team. Does anybody has a good recommendation, what tool to use where many people have control over one remote computer?
I looked at some tools myself already, but I only found pair-programming-tools (such as tuple.app), but they are focussing on a good collaboration as a pair only. Use-together (use-together.com) go exactly in the right direction as multiple people have a mouse and keyboard at the same time, but unfortunately the limit for people collaborating together is set to 4. As our team varies between 6-8 people this is again no option for us.
As I can imagine that a lot of people might already solved this kind of challenge, I´m happy to hear, how you did it!
May I ask why you want your whole team to control the sharing? In my experience it is usually one person driving the Jira and there should be almost nothing to do other than moving between the participants lanes and maybe update someting that was missed before the daily?
If you explain what you do, I am sure we can find a solution for it :)
As the title suggests, I've got a problem I just cant find a solution to. I've googled every possible angle and just cant seem to find a solution to this problem.
Basically, I'm missing 2 Link Types -- Affects and Affected By
All the others are there.
For example if i was to create a new Bug WI go to All Links -> Link To there is no option for Affects or Affected By.
Ive checked the data warehouse and the Work Item Link Type Dimension for the cube in analysis services, and they are in fact not in there.
I've tried everything i cn think of,
Ive also exported the linktypes from one of our development environments (which includes the link types) and imported them back into the production server using witadmin... This did not work,
I'm really lost with this one and there just doesn't seem to be any solutions on google, which i find hard to believe but i've spent the last 4 hours looking.
I would really appreciate it if some one could provide some help on this one, im willing to try anything.
It just seems strange why just these 2 link types would be missing.
We use our own process template which is just an extension to the MSF For Agile Software development v5.0 process template.
Seems the only way to solve this issue is to force TFS to recreate the Tfs_Warehouse database and reprocess the cube..... PROBLEM SOLVED
There is Ruby on Rails (1.8, 2.3.2) project. First version of project was made by some organisation. I will implement next versions of this project without any help from this organisation. I will be able to talk with developers from previous development team during meeting (1-3 hours).
Project statistics: ~10k LOC, 1.0/0.6 code to test ratio, rspec
What questions about project can you recommend to ask?
First review the entire project and to figure out as much as possible so you have context and can actually understand what they tell you.
Ask
If you can record the conversation
For an architectural overview
Why they made certain architectural decisions over another
A complete list of dependencies (if you can't figure that out on your own)
What the biggest problems are
Which parts of the projects are always / never being fixed
What the Achilles' Heel of the project is
What will cause the biggest headaches
What security issues are there and what the constraint is to fixing it
What would you do next if you were me?
What you should know that you didn't ask (most important question)
Also, don't be judgemental, you want them to reveal any problems they know about. There are probably tons of things wrong with the app that they are embarassed about, which you need to know sooner rather than later. They're not going to open up to you if they don't trust you.
I would ask for a code walkthrough. Not line-by-line, but more for the overall structure of the project, relationships between individual modules, etc.
Find out the Why's. How is easy enough to see in the codebase, but the why is sometimes impossible to figure out, and will bite you in the ass.
For instance...
Which parts of the application were the biggest performance issues? Which of those issues were resolved? Which are still issues?
Why did you opt for pattern / tool / library x? What other things did you consider? Why?
This will hopefully. (Hit some wood.) Help keep you from having to trudge through the same learning curve and mistakes that the first team had to deal with, and should give you good insight into where the first team actually made a poor choice, instead of making a choice based on factors you have not accounted for yet.
Ask if the new features will cause any major changes to the existing code (architecturally) and what the implication of that will be with other dependent parts of the application.
Also get their emails, as you will have more questions.
One of the most important things, in my opinion, is to get as much technical documentation as you can prior to meeting with them. You should try to go into the meeting as informed as possible, so that you not only know what areas you need to focus on the most, but also to have a preexisting knowledge of how some of the subsystems relate to each other.
Also, do not be afraid to ask what they would have done differently, if given the chance. Some of the best ideas come too late in the development process to be implemented - be it from library availability, change in requirements, change in team, etc.
Bring cookies (or pizza, beer, or wine as appropriate); you will want them to have positive memories of you for when you call with questions.
Edit: to put my answer in the form of a question: "May I offer you a home-baked cookie?"
Perhaps you have done this already, but I would make sure you can:
Checkout the latest version
Run all the migrations
Run all the tests
Deploy (even if to a staging server)
Run the application locally
Before you go to the meeting, so you can make sure you can by the time it is over.
Other things that might be useful
data model
UI wireframes
bug tracker data / issue tracker data
who are the customers / people representing customers
development environment configuration
source control locations, etc.
explanation of special configuration settings
Wow! All great answers, right down to the cookies.
My contribution assumes that this is your one and only chance to access the old dev team, therefore you need to kick it up a notch:
Agenda. Split the meeting into several parts, for instance:
A quick (15 min) introduction and arch overview
One on one with team members.
Design review as a group, etc.
Positive Energy. Especially if the relationship is inherently difficult, keep a positive focus by postulating: what improvements would you put into the next version - (rewrite is not an option, right Joel) - capture every nuance, and drill down past their comfort level only nearer the end.
Facilitator. Use a trained design meeting facilitator. They can help prep for the meeting, conduct pre-meeting interviews, design the agenda. During the meeting they can drive the intensity, and keep the focus. They can also suggest forms of capturing what can be a fair amount of information.
Also, I would try to id all design artifacts beyond the code, if any, and come to an understanding of how accurate it is. This may include doing design reviews of key elements of these documents vis a vis the as-built system.
Don
How do I know if I am overanalysing?
I've been chasing a problem the last 3 days. I've been through many designs and reached a complex solution using about 3 classes. Having discussed with a colleague, I realized that all I need is one method and a struct. How can I avoid being an architecture astronaut?
I find that if I can't come up with a good clean solution in 30 minutes, it's almost always best to discuss it with someone else.
Even if they have no idea how to resolve it, it often triggers a better design or solution.
So talk to someone about it.
Personally, I can't really complain about anyone who actually PLANS their software first! I do this, but I know LOTS of programmers who only know how to just jump right into the code... and I often have to fix such code...
That said, what your really asking is how to know when there is a better solution to the problem.
The advice I have for you is to ask yourself repeatedly: Am I thinking about the details of my solution, or about the real problem?
The best way to avoid become an architecture astronaut is to get into the habit of jumping right in. The best way to jump right in is to write a few tests that will pass when your implementation is complete and correct. That forces to you confront what "done" means from the outset, and it provides a sanity check on the code that will follow.
Then head for a solution.
You might now get there the first time, but the exercise of starting with an idea of what "done" means firmly in mind will help you to ask better questions as you go, and having some acceptance tests done ahead of time will help cull the design space down to something reasonable.
I used to suffer from this problem. Designing a solution which could handle a lot of growth in the future and what not. Ensured it had good abstraction resulting in the type of concern you had above.
I then dumped this approach and whacked it all into one big dirty class maybe two. After that I re factored it until it resembled something I'd want someone else to work on.
I like doing something quick & dirty first, and when it works, I refactor the code step by step until I'm satisfied with the design.
This is also the TDD approach.
I find myself following these three steps to find an 'ideal' solution:
If I had all the time and resources in the world, what would be the best solution in any way. (Technologically, Logically, Performance-wise, optionally solving a few related issues, re-writing modules you find could do better...) Do your (over-)analysis here, just to get to know about as mush as possible. Run tests, statistics and create proof-of-concept's.
How is it different from the current situation. What is the difference between the results of the two solutions. Is there a faster way to get to the same or similar result. Why would this or that change solve the problem at hand. Do some more tests, statistics, update your proofs-of-concept.
Find a way to implement the required changes, and only the required changes, drop anything not essential to this change. Check you're not modifying anything that was not having the problem. Test this, review changes to code, logic, structure; and minimize them if at all possible.
This sounds very restrictive (and a lot of work), but in fact I find myself I end up adding an entire table to the database in some cases. Part of the work (because it's a lot of work to get 100% sure of something) is checking all existing code keeps working exactly the same with this extra table to join in.
To top that, in most cases here at work we need to cater for 'transitional data' that remains in the system from before the update, that will have to get produced and shipped all the same after the update.
I took a data structures class in C++ last year, and consequently implemented all the major data structures in templated code. I saved it all on a flash drive because I have a feeling that at some point in my life, I'll use it again. I imagine something I end up programming will need a B-Tree, or is that just delusional? How long do you typically save the code you write for possible reuse?
Forever (or as close as I can get). That's the whole point of a source control system.
-1 to saving everything that's ever produced. I liken that to a proud parent saving every single used nappy ever to grace the cheeks of their little nipper. It's shitty and the world doesn't benefit from it's existence.
How many people here go past the first page in google on a regular basis? Having so much crap around only seems to make it difficult to find anything useful.
+1 to keeping code forever. In this day and age, there's just no reason to delete data which could possibly be of value in the future. Even if you don't use the B-Tree as a useful structure, you may want to look at the code to see how you did something. Or even better, you may wish to come back to the code someday for instructional purposes. You'll never know when you might want to look at that one particular sniblet of code that accomplished a task in a certain way.
If I use it, it gets stuck in a Bazaar repository and uploaded to Launchpad. If it's a little side project that pitters out, I usually move it to a junk/ subdirectory.
I'll use it again. I imagine something I end up programming will need a B-Tree, or is that just delusional?
Something you write will need a B-tree, but you'll be able to use a library for it because the real world values working solutions over extra code.
I keep backups of all of my code for as long as possible. The important things are backed up on my web server and external hdd. You can always delete things later, but if you think you might find a use for it, why not keep it?
I still have (some) code I wrote as far back as college, and that would be 18 years ago :-). As is often the case, it is better to have it and never want it, than to want it and not have it.
Source control, keep it offsite and keep it for life! You'll never have to worry about it.
I have code from many, many years ago. In fact, I think I still have my first php script. If nothing else, it's a good way to see how much you have changed over time.
I agree with the other posters. I've kept my code from school in a personal source code repository. What harm does hanging on to it really do?
I would just put it on a disk for historical sake. Use the
Standard Template Library - one mistake people make is assuming that thier implementation of moderate to complex data structures are the best. I can't tell you how many times I have found a bug in a home grown B-tree implementation.
Keep everything! You never know when it will save you some work. About a year ago I needed some c code to parse an expression, tokenize it for storage, and evaluate the results latter. Ugly little piece of code.. But is seemed familiar, as it should have- I had to do a post-fix evaluator in college (30 years ago)- and still had the code. Admittedly it needed a little clean-up, but saved me a couple of days of work.
I implemented a red black tree in Java while in in college. I have always wanted to find that code again and cannot.
Now I do not have the time to recreate it from scratch since I have three kids and do not develop in Java.
I now keep everything so that I can relearn much faster. I also find it fascinating to see how I did something 1, 5, 10 years ago. It makes me feel good because I either did it right or I am better now and would do it differently
If I ever go back to college to give a lecture to future students it in on the list of things to do:
Save everything...
I'm a code packrat, for better or worse, but I guard it, because sometimes it's client-confidential.
On occasion, this has been really useful, like if a client lost their stuff, or their documentation.
I lost a lot of old code (from 10 years ago) because of computer failure that wasn't backed up but in fact I do not really care because I do not really want to see code that is programmed in very old language. Most of this code was written in VB5...
I agree that now it's easy to keep everything but I think sometime it's good to clean up our backup/computer storage because it's like in the real world, we do not need to keep everything forever.
Forever is the beauty of the electronic medium. That's one of the most attractive aspects for me.
But, the keeping of it depends on your coding style, and what you do with it.
I'd suggest tossing your code if you're the type that...
Never looks back.
Would rather re-write from your memory to improve your craft.
Isn't very organized.
Is bothered by latent storage to no end.
Likes to live on the edge.
Worships efficiency of memory.
Logical reasons for tossing could would be...
It bothers you.
It disrupts your workflow by getting in your way.
You're ashamed of it.
It confuses you and distracts you.
Like anything that takes up physical space in life, it's value is weighed against it's usefulness.
All my code is kept indefinitely, with plans to return to it at some point, reflect, and refactor. I do that because it's fun to see my progress, and provides very accessible learning experiences. Furthermore, the incorporation of all my code into a consolidated framework is something I work towards all the time.
Forever...
Good code never dies. ;)
I don't own most of the code I develop: my employer does. So I don't keep that code (my employer does - or should).
Since I discovered computing, I wrote code for devices that no longer exist in languages that are no longer worth. Maybe there is some emulator but keeping that code and running it would be nostalgia.
You can find B-tree information (and many other subjects) on Wikipedia (and many other places). There is no need to keep that code.
In the end I keep only code that I own and maintain.