I have a question in my mind will you tell me what is the "BUG"??

Answer 1

@InNoobWeTrust: I'm curious... why do you prefer the word "programmer" to talk about bugs and what would the mistake be to use "developer"?

Answer 2

This post has the answer.
https://www.sololearn.com/discuss/381260/?ref=app

Answer 3

bug is an insect
bug in codes is an error

Answer 4

Back when computers were huge machines with moving metal parts they often had to clean bugs out of them when the machines were not working right. This is the origin of bugs.

Answer 5

As in, bugs in codes?

Answer 6

@InNoobWeTrust: I saw your response to my question a couple hours ago. Why did you delete it?

In your original response (now deleted), you suggested that the title "developer" should be reserved for those who are experienced in software development, as well as, confident and proud in their code. You also explain that the title of "programmer" should be reserved for those who are new, don't know what they are doing yet, and write code with a lot of bugs.

Technically, there is absolutely no difference between these titles and they can be used interchangeably. Perhaps the distinction between "experienced" and "inexperienced" developers are better expressed using adjectives such as "junior", "intermediate", "senior", "lead", or "architect".

That said, I am curious, how would you classify your level as a "programmer/developer"?

Answer 7

@InNoobWeTrust - I can appreciate your frustration with working with other people's "bad" code. Unfortunately, there is a countless amount of "bad" code throughout the world. It's an unescapable reality. Heck, I shutter to imagine what my code looked like some 20 years ago. I certainly lacked the vast experience accumulated over the years to write code that would be as maintainable, extensible, reusable, secure, performant, and tested as today.

As an industry, we've evolved significantly from the days of waterfall methodologies for project management bound by unrealistic deadlines, with limited budgets, and unclear requirements. There was no such thing as a project that was well budgeted with clear requirements and realistic deadlines. Software development is simply too complicated with too many unknown variables that shift throughout the duration of a project. Consequently, bad programming practices are unwittingly adopted to attempt to deliver against a project doomed to fail from the beginning.

Fortunately, the industry has learned from this "lie" we referred to as project management. We've shifted to agile methodologies that consistently work (at least for me) from project to project.

We also have amazing development processes, workflows, and tools that go beyond simply writing code. Practices such as paired programming, TDD/BDD, unit/integration test frameworks, and CI/CD have been instrumental in delivering robust applications with minimal bugs.

In fact, it's not just about the developer writing "bad" code. Sure, that's a problem that will improve over time. However, how would a developer trust the "good" code they write doesn't somehow impact the "good" code someone else wrote in another part of the application. You can't without thorough regression testing. Even then, it's not 100% guaranteed. By automating tests with well thought out specs, such colliding conflicts are quickly identified and greatly reduced.

Anyway, thanks for sharing your thoughts.

Answer 8

Part A:

@InNoobWeTrust... It sounds like you, indeed, had an awful experience with that project.

A couple of thoughts came to mind as I was reading about your nightmare project.

First, it sounds like the project owners didn't understand the agile process. The instant a deadline is set, arbitrary or not, it's no longer agile. Rather than focusing on deadlines, the process focuses on the velocity of a team based on the amount of work delivered from previous sprints. Sprints are short periods of time (commonly 2 or 3 weeks) where the team will focus on delivering a set of feature stories. Each feature story is estimated based on points rather than man hours. These points are based on a group assessment of the effort for one story compared to other stories already completed by the team.

Here is an example feature story:
- #3 - As a user, I want the ability to reset my password, so I can access my account in case I forget my password.

This might be related to a parent story such as:
- #2 - As a user, I want a login page to enter my credentials, so I can access my user specific content.

And both of these might belong to a larger epic such as:
- #1 - As a user, I want the ability to securely access and manage my profile, so I can make edits when needed.

Story #1 might have been set to 21 points because it involves quite a bit from password storage, hashing, web pages for login, password reset logic via email and confirmation links, etc.

This would then be broken down to smaller stories like #2 and #3 which each might have been estimated as 8 points each.

Later a new story might be added such as:
- As a user, I want my login session to expire after 3 days, so I am required to login after a few days.

This could be assigned points as low as 1, 2, or 3.

Ultimately, these points reflect the relative effort compared to other features completed. Some story features will be simple, others will be more involved.

[To be continued in Part B]

Answer 9

Part B:

Imagine the agile team sets their sprint duration to 2 week periods. Your team will need to complete a few sprints to determine the realistic velocity. Velocity is based on the total number of points completed in a sprint. This can be affected based on the number of developers, the skill level of the developers, and their availability to work on the project. Let's say your team has 4 developers with 1 super hero developer (at 20 points per sprint) and 3 junior developers (each at 10 points per sprint). The velocity for this team might be 50 points per sprint. This would be based on the average number of points completed after a few sprints.

Once this is established, forecasting can begin to take shape. This involves an evaluation of the backlog of feature stories required to be completed for a specific milestone in the project. Let's say a rough breakdown of the backlog stories comes to a total of 600 points. Based on the current velocity, it would take roughly 12 (2-weeks) sprints to complete. This would take 6 months with the current team and backlog.

If an arbitrary target date needs to be set at 2 months, the project owners have a few options that may accelerate this. One option is to add 1 to 3 additional senior developers increasing the velocity to 70 or 110 points per sprint, which translates to 4.3 and 2.7 months respectively. Another option is to reduce the backlog until enough is trimmed off to accommodate a 2 month target.

Regardless of the efforts to adjust velocity and target the 2 months, the project should never be date driven. Everything in the forecasting should be based on previous sprint data which reflects the actual capabilities of a team.

Otherwise, the project is at a very high risk for failure.

[To be continued in Part C]

Answer 10

Part C:

All said, it is also the responsibility of the developers to take ownership in managing expectations. If a project starts to impose aggressive deadlines with an unproven team, developers need to pump the brakes and provide guidance on what needs to change. If the product owners have no interest in listening or changing, then it's time to bail. Otherwise, you'll find yourself in the same horrific experience you were previously in.

Sorry for spending so much time on this topic. I do hope this sheds some light on what a smooth project could look like.

Ultimately, I wish you the best of luck on your current and future projects. Once you get a taste of working with a good team, you'll always know what to look for throughout your career.

Answer 11

a bug is what bugs you. bugs= errors/glitches

Answer 12

In computer technology, a bug is a coding error in a computer program. The process of finding bugs before program users do is called debugging.