Tag Info

Hot answers tagged

265

When an organization has higher-than-usual turnover, there's ALWAYS a reason and it is ALWAYS management. If the only way an engineer can get a raise is to change jobs, he'll do it. If the only way an engineer can get better working conditions is to change jobs, he'll do it. If the only way an engineer can see his wife and kids occasionally is to change ...


185

The premise of your question is simply incorrect: Software isn't "less reliable" than a car. There are billions upon billions of devices out there that run embedded software 24x7, for years on end, with no problem. Heck, some of it are in cars, and control/monitor the engine. So, how can software be less reliable than a car, if cars themselves rely on ...


120

It has to always be OK, because there is no such thing as bugless software.


115

I design software and mechanical parts. It is complexity. Because there are millions of "parts" in modern software. Software parts are very complicated and have a lot of STATE. A mechanical non-moving part has no state. A mechanical moving part has its position (one variable). A program that is running and uses 1Mb of RAM has a million bytes of state. ...


105

You cross the line when You have measured that your code is too slow for its intended use. You have tried alternative improvements that don't require mucking up the code. Here's a real-world example: an experimental system I am running was producing data too slowly, taking over 9 hours per run and using only 40% of CPU. Rather than mess up the code too ...


88

If many people are leaving the job, then it is a clear sign that the work environment is not suitable for them. This can be because either the work environment is generally poor, e.g. poor management, a lot of overtime, poor job satisfaction. But it can also be because the company does not provide the means for the individual developer to pursue his ...


75

Yes. Because no matter how good you are, you can't think of everything. You will also be asked to make your software do things that you never intended for it to do. You will also never have requirements that are so clear that you will be able to think of every possibility to make sure the code doesn't break. You will also work with other people's ...


73

Yes For the same reason that a chef tastes his food while cooking it.


72

Number 1: Using source control. This is the only one that I absolutely wouldn't, under any circumstances imaginable, ever, negotiate about.


56

It's a matter of consumer choice. If consumers demanded software to be as reliable as my Honda Civic (as opposed to my old Ford Maverick), it would be. Some organizations demand software that reliable, and they get it, typically for embedded software, sometimes for safety-critical things like space missions and air traffic control. The software still ...


48

Build it well. Building it "fast" is a logical fallacy if you look at the big picture. It will prevent you from ever having it built well, and eventually you will become bogged down by bugs and fundamental architecture flaws that prevent refactoring or even makes adding new features next to impossible. Building it well is actually the opposite. At first ...


48

It's a false dichotomy. You can make code fast and easy to maintain. The way you do it is write it clean, especially with as simple a data structure as possible. Then you find out where the time drains are (by running it, after you've written it, not before), and fix them one by one. (Here's an example.) Added: We always hear about tradeoffs, right, such ...


46

I think its a good thing to have a post-interview with people who leave the company. That way he can get a heads-up on the real problem why people leave. It is otherwise very difficult to find a remedy.


41

A Duck From http://www.codinghorror.com/blog/2012/07/new-programming-jargon.html: A feature added for no other reason than to draw management attention and be removed, thus avoiding unnecessary changes in other aspects of the product.


34

My experience is that development teams (but in general, any team) consist of 3 types of people: those with a built-in drive for quality, those who are only in it for the money (beer / girls / whatever) and couldn't care less however you try to motivate them, the "mediocre" ones (for lack of a better word). The last group is the largest, and they tend to ...


32

Its a judgement call. Remember, a bug can be many things. If its a major piece of functionality thats flat out not working, then you fix it first. If its something minor that has minimal or no real impact on the program's usefulnes, you might let it slide. So look at it from a cost/benefit viewpoint. You ship products with known bugs when the total cost ...


28

Here are some of the techniques that Google uses. Hire good developers who are likely to produce reliable code. Unit test heavily. Use code review. Set up a continuous build to catch integration issues. Have dedicated QA departments. Meaning both people testing, and automated programs (for instance using Selenium) that simulate end users. Have monitoring ...


26

Do you use source control? Required Can you make a build in one step? Nice Do you make daily builds? Nice Do you have a bug database? Required Do you fix bugs before writing new code? Nice Do you have an up-to-date schedule? Required Do you have a spec? Required Do programmers have quiet working conditions? Required Do you use the best tools money can buy? ...


25

there are many thousands of parts that make up a car. If only a computer (and the associated software) was that simple. The computer has what a gigabyte of memory? Billions of flip-flops? A terabyte of disk? Trillions of "moving" parts? The software may have 10s of thousands or 100s of thousands of individual lines of code running. Plus that many ...


25

Multitier Architecture When you have Layers on Layers on Layers on Layers... you see my point here, in your application. I call it Over Layered Architecture Over abstraction in such way that you get lost in the code. Futuristic Architecture This happens when the solution is too futuristic. In reality no one can predict new requirements. Therefore most of ...


25

When you've profiled the code and verified that it is actually causing a significant slowdown.


25

In my OSS existence I do a lot of library work aimed at performance, that is deeply tied to the caller's data-structure (i.e. external to the library), with (by design) no mandate over the incoming types. Here, the best way to make this performant is meta-programming, which (since I'm in .NET-land) means IL-emit. That is some ugly, ugly code, but very fast. ...


25

Refactor the existing source code. I know it sucks but if there's a lesson I've learned in development its that you don't just throw away a working project because the code is terrible. Your game is working. Keep it that way. Keyboard events are being handled in gigantic if blocks? Spin that off into a class and segregate functionality into methods. ...


24

Everyone can quit sometimes. You need to adapt a culture of quitting. But there is one thing that we all can do. In fact, let’s all do it together, right now, right this moment. Employees, go ahead and say to yourself: I know that I will quit my job, and there’s nothing wrong with that. Now it’s your turn, employers/managers: I know ...


23

Are there any statistics available to how much longer it will take to develop applications when creating unit test during the development compared to just coding? There is some very interesting research about this. Read the following whitepaper: Realizing quality improvement through test driven development: results and experiences of four ...


22

This is not normal for software engineers that love their working environment. Use the Joel Test to create the best working environment for developers. As your friend would attest, though these things have costs, so does turnover. The cost (time or money) in creating a better working environment and a better running software team will easily be offset by ...


22

I don't think that "youngsters" leave just because of salary - If anything, younger folks with less responsibilities and a longer career ahead of them can afford to take risks or work or fun things that us Dinos can't. However, I can certainly see them leaving if the Boss thinks that three newbies are better than a single veteran - who would want to become ...


22

That's an interesting question. I have always felt that the Joel Test was a lot like code smell; scoring a 12 doesn't mean that the company is doing everything right, and scoring an 8 can indicate that there are some bad practices but doesn't necessarily mean that the company is run poorly (but like code smell, you should tread warily). Instead of focusing ...


22

Code generators cannot generate better code than the person who wrote the generator. My experience with code generators is that they are just fine as long as you never have to edit the generated code. If you can hold to that rule, then you're good to go. This means you can reliably re-generate that part of the system with confidence and speed, automatically ...


22

Wait until you have about three hacks because of the same problem and then refactor. If you are just avoiding a single hack, then I suspect you do not actually have enough information to determine the best solution to the problem. I suspect you'll be able to find a better solution by delaying its implementation until more problems of the current solution ...



Only top voted, non community-wiki answers of a minimum length are eligible