7 things your boss doesn't know about software development

　　English Original:7 things Your Boss doesn ' t understand about software development

Does your boss not understand your job? This article will help you to better understand why your boss doesn't understand software development.

Your boss may be really good. I've met a few really good bosses in my own programming career, but even the best bosses often seem to fail to understand software development.

In fact, what I want to say is that when it comes to more than just a few elements of programming, most software development managers are a bit short-sighted.

So, I compiled a short list to illustrate some of the most confusing aspects of programming for your boss, development manager, Technology geek, and so on.

　　1. Technical debt is the most drag on the project

Working on a code base full of technical debt is like running in a heap of mud. At first, when the mud is not very thick, barely walk past is not a problem, but when there is a 1 meters deep, you are unable to move.

One of my favorite writers, the author of "7 Habits of Highly Effective People", Steven Covey, calls it "p/pc balance" or "yield vs capacity." ”

In general, managers and other non-technical personnel are willing to sacrifice quality when driving productivity--like a goose that kills a golden egg--and incur technical debt.

Of course, by twisting the goose's neck and threatening it, you may be able to get more eggs for the time being, but the dead goose will never lay eggs again.

If your boss is suffering from a non-technical debt and doesn't know how technical debt is slowing you down, then it is recommended that you tell him about the terms of the "7 Habits of Highly Effective people" on technical debt in the P/PC balance.

Most managers may have read this classic book, so it's difficult to write new features than you say because the codebase is too bad, and it's easier for them to understand the ideas in the story.

　　2. Estimates are mostly nonsense

Most of the projections in software development are nonsense.

This, you know, I know, even the poor project manager of the team knows--of course, he may not know, but he should know.

Predicting anything in software development is very, very difficult, because accidents can make you impossible.

Every software project, each task is new. Every time you sit down to write code, there's always something unexpected happening with the crap.

But that's the way it is. No one should be responsible for this. It's not your fault, it's not my fault, it's not anybody's fault. It's going to happen.

However, we are still tempted to play this "predictive" game.

"Joe, how long do you need to build a customer login page?" ”

"Oh ... Uh ... "Think about it for a moment," 2 days ... Oh wait--"forget the CYA double." "--it will take 4 days. ”

"Well, I'll give you 5 days."

"Well, that's 5 days." ”

A good solution is to break down the task to a small enough level to keep all estimates within 4 hours.

Experience tells me that a half-day estimate usually gives you the decency to finish the job. Over this point, then you are nonsense.

　　3. Can be completed immediately or quickly

Urging professionals is usually a bad idea.

I've learned this from writing code for more than 15 years now, so I know that when I hire someone else to do something, if I push them, maybe they will finish on time, but the result will be useless.

Unfortunately, I have found that many software development managers do not seem to know the universal truth. Somehow, they think the code can be fast and good.

Do not misunderstand my meaning, I also admit that there are exceptions. Sometimes, you can actually write good code quickly, but usually it's always slow to deliberately.

It is also unfortunate that most programmers, when told to hurry to complete a task, often choose to take shortcuts and speed up the process by sacrificing quality.

More unfortunately, such "code quick" is often hailed as a hero because they are able to accomplish tasks faster because they never postpone or ask for more time.

However, these "code quick" tend to write the code in a muddle, leaving others with a string of technical debt.

If you are dealing with a development manager who does not understand the relationship between quick and good, then you'd better come up with some statistics to show that late fix bugs cost more than pre-prevention.

The larger the organization, and the more cumbersome the business process involved, the higher the final cost of completing the task quickly than the correct task.

(for the classic book of this question-the myth of the people of the Moon.) ）

　　4. There are developers who are actually helping

There is a fact that we have all come across a programmer who does more harm to the team than the benefit.

Different programmers have a huge difference in their ability and skill levels in the field of software development.

In fact, some software developers are so bad that every line of code they write at work is a waste of company time and resources.

This type of developer might want to pay the company, not the company, to pay him money.

This may be obvious to you, but not to the boss. For example, in your opinion, Joe may be a complete loser who needs to be dismissed because he will only do some "gold-stone" folly. Everything he touches becomes a useless "stone".

But what can you do if your boss doesn't understand that these people are worse off in the team?

Well, most software developers are afraid of being considered a gossip boy--I totally understand.

But...... You have to do this. This is the right one. If someone is really a pest in the team, it's your job to let the manager know that.

I know it's going to get you into an uncomfortable situation, but if you don't report it, you're not a competent programmer. You will be an accomplice in killing the project.

As for the so-called report, just be cautious and give some hints.

For example, you can say this:

"Hey, I don't like to do this kind of thing, but I think if I were you, I'd want to know if someone was directly interfering with the team. So, I think it's my duty to tell you something I've been observing.

......

Of course, these are just my observations, so please consult with other team members, judging by your own experience. ”

Or, if you can also use this less tactful way:

Hey Joe is a cook. It was too slow for him to write the code. In fact, his only merit is that he is slow, because since he came, the project basically can only move at a snail's pace. It's too late for you to know him correctly. ”

　　5. Better equipment is one of the cheapest productivity you can invest in

I hate it when programmers tell me that their miser bosses don't give them a second monitor, or that they're using a computer that's 5 years old.

To be honest, I really don't understand why some software development managers don't agree to spend $2k on hardware improvements for those 8k+ dollar programmers-a good investment.

Old hardware equipment so that programmers really annoyed, very irritable!

Whenever a programmer complains about this kind of work, I usually advise them to seek another job, because the boss's stupidity is probably no cure.

Don't say anything, I tell you:

Good equipment allows software developers to work more than one hour a day, making developers more productive. Even if only half of the value I said, the total time added up will not be less.

If the count is 250 working days a year, then it is 250x$35 dollar =$8750. Even if you cut it down by half or One-fourth, it's still a good investment.

If your boss doesn't understand the truth, honestly, I don't think you can do anything about it. If you really like your current job, then you can only invest in yourself.

　　6. The risk of new technology is not as high as you think.

Nothing makes the software development manager feel more frightened than mentioning. NET's latest and best JavaScript framework version.

This is already a tacit minefield.

Once in a while, the software vendor released a new version of the framework or patch every other year or so, so the cost of the error would be quite high.

Once upon a time, most of the source code was sealed in the "tomb" and was not allowed to be accessed by anyone else, so once the company no longer supports it, you are in a dilemma.

But now, things are different.

Today's frameworks, sometimes even on a daily basis, release patches, and most popular frameworks are open source, so the stakes are low.

Of course, you can also broken broken falls, but this situation is not many, and only need to make a slight change, rather than a sword wave, good bad all cut off.

So, if the programming manager is still alive in 1980, then you may need to point out what has changed for him and why it is more dangerous to stay in the old version of the framework or library than to upgrade it.

The security hole in the fear strategy is a good breach.

　　7. The superfluous business analyst and project manager

I know I might offend a lot of people next, but I don't care. I'm telling the truth here, I'm the kind of person who can say what they see.

Of course, the first thing to state is that there are some good business analysts and project managers-but honestly, most business analysts and project managers are worthless.

Once these roles were needed to develop the project.

But now, in most cases, we don't need them anymore.

Software developers should talk directly to their customers so that they can get their own understanding of their customers ' needs. So we don't need business analysts.

It's a disabled post because they're doing half the work a software developer should do, but it doesn't help the other half.

And the project manager is more magical, his goal seems to be running against us to develop, to make a mess of everything.

I know they are good intentions, but in the current agile world, project managers are not playing a role, so what do they want them to do? They are walking around trying to make themselves seem important, trying to figure out what they can do, and in the end, they will only hinder you.

Many of the software development managers ' ideas remain in the past, staying in a more meaningful era, listening to the so-called "trends" of the world's top 500 consulting firms – many software companies need more high-paying advisers to meet these jobs, according to the companies.

If your manager still doesn't understand, the only solution is to receive an agile education.

I do not recommend that you tell your boss directly that "business analysts and project managers are simply wasting oxygen"-which may not be easy to accept-so instead I focus on explaining how an agile team should work and what roles it needs.

It is then obvious that in a real agile environment, there are no business analysts and project managers, and they may be better suited as Scrum administrators or product owners.

　　Active and proactive

Of course, these things I said above, some I might say in a joking tone. But in reality, the understanding of software development between software development managers and software developers is often disjointed.

I'm sure the software development Manager will complain that software developers don't understand the business side and don't know the difficulty of arranging meetings-but that's another matter.

In any case, the key point is this is not a confrontation, but a solution to the problem of poor communication--at least to a certain extent--can be resolved through reasonable communication and communication.

Taking a positive, not confrontational, approach is often the best way to solve these problems.

Do you have any ideas? Welcome to share.

7 things your boss doesn't know about software development