Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Search - "agile family"
-
TL;DR :
"when i die i want my group project members to lower me into my grave so they can let me down one last time"
STORY TIME
Last year in College, I had two simultaneous projects. Both were semester long projects. One was for a database class an another was for a software engineering class.
As you can guess, the focus of the projects was very different. Databases we made some desktop networked chat application with a user login system and what not in Java. SE we made an app store with an approval system and admin panels and ratings and reviews and all that jazz in Meteor.js.
The DB project we had 4 total people and one of them was someone we'll call Frank. Frank was also in my SE project group. Frank disappeared for several weeks. Not in class, didn't contact us, and at one point the professors didn't know much either. As soon as we noticed it would be an issue, we talked to the professors. Just keeping them in the loop will save you a lot of trouble down the road. I'm assuming there was some medical or family emergency because the professors were very understanding with him once he started coming back to class and they had a chance to talk.
Lesson 1: If you have that guy that doesn't show up or communicate, don't be a jerk to them and communicate with your professor. Also, don't stop trying to contact the rogue partner. Maybe they'll come around sometime.
It sucked to lose 25% of our team for a project, but Frank appreciated that we didn't totally ignore him and throw him under the bus to the point that the last day of class he came up to me and said, "hey, open your book bag and bring it next to mine." He then threw a LARGE bottle of booze in there as a thank you.
Lesson 2: Treat humans as humans. Things go wrong and understanding that will get you a lot farther with people than trying to make them feel terrible about something that may have been out of their control.
Our DB project went really well. We got an A, we demoed, it worked, it was cool. The biggest problem is I was the only person that had taken a networking class so I ended up doing a large portion of the work. I wish I had taken other people's skills into account when we were deciding on a project. Especially because the only requirement was that it needed to have a minimum of 5 tables and we had to use some SQL language (aka, we couldn't use no-SQL).
The SE project had Frank and a music major who wanted to minor in CS (and then 3 other regular CS students aside from me). This assignment was make an app store using any technology you want. But, you had to use agile sprints. So we had weekly meetings with the "customer" (the TA), who would change requirements on us to keep us on our toes and tell us what they wanted done as a priority for the next meeting. Seriously, just like real life. It was so much fun trying to stay ahead of that.
So we met up and tried to decided what to use. One kid said Java because we all had it for school. The big issue is trying to make a Java web app is a pain in the ass. Seriously, there are so many better things to use. Other teams decided to use Django because they all wanted to learn Python. I suggested why not use something with a nice package system to minimize duplicating work that had already been done and tested by someone. Kid 1 didn't like that because he said in the real world you have to make your own software and not use packages. Little did he know that I had worked in SE for a few years already and knew damn well that every good project has code from somewhere else that has already solved a problem you're facing. We went with Java the first week. It failed miserably. Nobody could get the server set up on their computers. Using VCS with it required you to keep the repo outside of the where you wrote code and copy and paste changes in there. It was just a huge flop so everyone else voted to change.
Lesson 3: Be flexible. Be open to learning new things. Don't be afraid to try something new. It'll make you a better developer in the long run.
So we ended up using Meteor. Why? We all figured we could pick up javascript super easy.Two of us already knew it. And the real time thing would make for some cool effects when an app got a approved or a comment was made. We got to work and the one kid was still pissed. I just checked the repo and the only thing he committed was fixing the spelling of on word in the readme.
We sat down one day and worked for 4 straight hours. We finished the whole project in that time. While other teams were figuring out how to layout their homepage, we had a working user system and admin page and everything. Our TA was trying to throw us for loops by asking for crazy things and we still came through. We had tests that ran along side the application as you used it. It was friggin cool.
Lesson 4: If possible, pick the right tool for the job. Not the tool you know. Everything in CS has a purpose. If you use it for its purpose, you will save days off of a project.1 -
I can understand (to a point) when non-devs use meaningless tech "buzzwords", but please, as developers, can we just agree not to spout nonsense?!
"Electron is so amazing, it's such a lightweight framework!"
"Django is incredible, it's so agile!"
Agile is a family of development methodologies, and Electron is about as heavyweight as a desktop application can possibly get...10 -
I applied for a position as an engineer for a nonprofit organization that helped kids across the country (and the world) and got the position. The people across the organization were wonderful and, without a doubt, mission driven to help kids and it felt good to do the work. The agile teams worked well together, every team had their roadmaps, and management always emphasized family first. The organization was making crazy money so we were given all the tools we needed to succeed.
Then, within a few months of my hiring, it was announced that the non-profit organization was being bought by a large, fairly well known for-profit company which had also been recently acquired by a venture capital firm.
The next thing we knew, everything changed all at once. We went from building applications for kids to helping this company either make money or build value for their owners. Honestly, I did not know what my day-to-day work was doing for this company. The executives would tell us repeatedly that we were expensive and not a good value compared to their other teams. It felt like we were only being kept until the systems were integrated and their had access to our decades of data.
You might think I'm being paranoid but a year after the acquisition, we still did not have any access to any of their systems. We operated on a separate source code solution and were not given access to theirs. When requests came from them that would facilitate them connecting applications to the data, it was to be considered highest priority.
The final straw for me was when I was told my compensation would be cut for the next year. We were strung along for the whole year leading up to it saying that the company was evaluating our salaries compared to others in the industry. Some of us figured that we would probably even go up knowing that we were underpaid for a for-profit tech company because we chose to work in a non-profit for a lower rate to be able to do worthwhile work. Nope! We were told that we were overpaid and they talked about how they had the data to prove it. One quick look at LinkedIn would tell you they must be smoking something that had gotten stale in a shoebox. Or they were lying.
So that was my rant. If you think you are protected from the craziness in tech right now just because you are writing code at a nonprofit, you might be wrong. Dishonest executives can exist anywhere.3 -
Ever since humans transitioned from hunting-gathering to farming, cats saved an unimaginable number of people. Dogs are fine at hunting and guarding the household, but they’re not sneaky enough to catch mice.
Mice destroying your food stash meant death by starvation for your whole family, no exceptions. Only something as agile, sneaky and alert as a house cat could catch mice effectively.4