Tag Info

Hot answers tagged

38

It basically comes down to "use the right tool for the job." If you have to interact with a user, you'll want some sort of GUI. We've got decades of research and experience showing that they make computing far more intuitive and productive. That's why GUIs have inexorably taken over the world ever since 1984: they just work better for interacting with ...


31

Eric Raymond's The Art of Unix Programming is the canonical work for the argument you're making. I won't try to condense his excellent book into a couple paragraphs. However, keep in mind that argument applies mostly to programmers, administrators automating tasks using scripting, or power users of highly technical software like CAD. Even with highly ...


27

I "make tools" when one of these is true: The task is annoying me The risk of human error in the task is too big The "risk" for the 2nd option doesn't have to be huge - the cost of building one small tool is usually small, so if all you save is the risk of running a 10-minute build again once a week, it will usually repay itself very fast. I try to make ...


22

Advantages of physical whiteboards: Usually cheaper. Even free software requires a server to run on, data backed up and so on. Easier to use than software, particularly for less technical people or those involved temporarily. Easier to customize. Write on it, add a sticky note, add a heart sticker and so on. Many software packages are less flexible or ...


16

The short answer is "no". The long answer starts with the realization that there are no absolutes in software development or most other fields: it all comes down to what you need and who will need it. A physical whiteboard is an awfully versatile and useful thing. You can write on it, you can tape things to it, you can put index cards on it with magnets ...


16

I think you answered your own question; whilst you'd like to use 1 tool, "a lot" of your colleagues prefer to use something else. Without a 'boss' to decide tooling, the majority rules and you need to go with the preferred tool. Now, there's no reason why you can't try to engage with them in discussion of tooling. You will have to take the initiative and ...


15

Having the ability to work with a CLI is hardly what I would consider backwards. It looks great on a resume especially if you can spin it on your resume like "used (powershell/bash) to build a suite of automation tools to send SMS messages when the Database was down". When I am responsible for hiring people, a working knowledge of the CLI is something I ...


15

It's not just unix that's driven by command line programs. Microsoft is heading that way too. Microsoft has been pushing powershell for some time now. All of their current server software (Exchange, Sharepoint, Server 2012, System Center, etc) can be completely controlled through the powershell command line. And powershell relies on small functions that ...


9

With experience I have found that just pushing hard on the grunt work is usually the most time-efficient. Making a tool is often tempting. I give up resisting when: The tool has more than one purpose. A good chess player accomplished two things with each move: block an opponents piece and free up a bishop. A beginner would probably need two turns to do ...


8

In my experience, code coverage is as useful as you make it. If you write good tests that cover all of your cases, then passing those tests means that you have met your requirements. In fact that's the exact idea that Test Driven Development uses. You write the tests before the code without knowing anything about the implementation (Sometimes this means ...


5

My rule of thumb is that when I have to do something for the third time, it's time to either write a little script to automate it, or rethink my approach. I'm not making a full-blown "tool" at this point, just a little script (usually bash or python; perl would work too, or even PHP) that automates what I did manually before. It's basically an application ...


5

The first thing to do is have very thorough automated offline regression tests. Make passing those tests a minimum requirement for what you officially use. Second, you need a dead simple way to fall back to the previous working version, for problems that your automated tests don't catch. For example, my Linux kernel was custom patched for a while. I ...


5

I would definitely not say it's a bad thing. The nice thing about CLI programs is that when implementing them you can have a very restricted scope. For instance, if I want to write a cat clone or "a program to print the contents of a file to the screen", that's very feasible with CLI. However, what if you didn't use CLI, well then you'd have a basic ...


5

First off, people do advocate 100% coverage: Most developers view ... "100% statement coverage" as adequate. This is a good start, but hardly sufficient. A better coverage standard id to meet what's called "100% branch coverage," ... Steve McConnell, Code Complete, Chapter 22: Developer Testing. As you and others have mentioned, code coverage for ...


4

The GUI and CLI both have their place. The GUI is great for allowing a user to perform certain canned operations quickly. The CLI is for when you want to do things the GUI doesn't allow you to do. The CLI is usually more powerful and harder to use. A good CLI tool allows the user to do things the person who wrote the tool never thought of. One example ...


4

I just remembered this: The problem with this of course is that in real life situation you can't easily measure those data to select the right cell in the table. And as it was mentioned in other answers, there are other variables (the risk of error, task is too boring to do it even once, ...) you need to add to the equation. So my answer is that it ...


4

Simple. Stop sharing the same development server. Give each developer his own environment in which to develop. This can be on their own box, or a VM each on the server. Then the existing 'dev' server gets renamed to 'integration server' and it is used as a quality check after development code is merged from a developer's branch to a mainline branch/trunk. ...


4

Debugging / TESTING! Unit test the heck out of your backend code. It's usually easier than unit testing frontend code, because the code isn't waiting for arbitrary clicks or keypresses. It's all "this data comes in, this data goes out". Aggressive unit testing will speed you up phenomenally because you don't have to go all the way back to the start to ...


4

Every project needs some kind of central leadership to call the shots and make decisions like that. In a company, this is usually the project leader appointed by management. In a large open source community, the leadership is often some kind of meritocratic community process where every participant can make suggestions and an expert group votes on them. ...


4

I recommend you review the needs and decide on what tools need to be common. For example you can't have some people using svn and others using git when there is a lot of code sharing. However when it comes to editors, differences may be ok. The time, cost and motivation for people to switch tools that are essentially about preferences is often not worth ...


3

This is a big problem in my experience. Tool building is usually left to a motivated developer who stops work to build the tool. This often interferes with the development even if it provides value. Tool building needs to be viewed as an integrated part of the development "Process". I remember attending code reviews where header errors would result in ...


3

If this tool is being used to produce production-quality software (especially if it is being used recursively, i.e. to develop itself), I would increase your up-front testing efforts, and wait on dogfooding until the release is stable enough that you are fairly confident you won't be breaking production code by using it. If you have to wait for the master ...


3

Ok, maybe I projected it a bit too dramatically, but you get the point. The problem is about setting processes/policies in general across all teams in a homogeneous/consistent fashion. I think that's the problem. Developers don't care (and often for excellent reasons) about consistent or global policies, and want the freedom to do what they think is ...


3

The argument from these folks is - the team would react by quickly creating low quality tests and thus waste time while adding no significant quality. This is an issue of trust, not tools. Ask them why, if they really believe that statement, they would trust the team to write any code at all?


3

Just as an addition to the other answers: There's no need to make this an either-or situation -- you can have an electronic board and a physical one. Our team uses an electronic board as the main working tool (we use Kanban) and as the authoritative source of information. The electronic board has all tasks, is updated as tasks are worked on etc. In ...


3

This may not fit your needs, but may fit another's. Org-mode for Emacs includes table.el, which, along with Org-mode's particular enhancements, provides an extremely robust solution for spreadsheets, all in plain text. More information (much more than the scope of this site) is available at Org-mode's website and manual, particular its spreadsheet ...


3

So I ask: Is there a tool that visually represents all the potential routes from which SetTotalControlsProperties() is called/CurTotal is set? It sounds like you're describing the Call Hierarchy feature found in several IDEs, including Visual Studio: If you can't use an IDE that has this feature, there are separate tools that generate calls graphs. ...


2

DOesn't solve all the problems, but, I always recommend a UAT environment that is as "production like" as possible. This includes all the security, access controls and procedures to which the production system is subject to. So if in production you can only change a parameter file by e-mailing it to a sysadmin and copying the project leader and business ...


2

In my experience, there's a few things to combine with code coverage to make the metric worthwhile: Code Reviews If you can punt bad tests back to the developer, it can help limit the number of bad tests that are providing this meaningless coverage. Bug Tracking If you have a bunch of code coverage on a module, but still get many/severe bugs in that ...


2

All of the other answers are good, but I'd add one more reason why it's valuable to spend time to build small tools (and customise your .vimrc, .emacs etc.): Sometimes you get creatively or motivationally "stuck in a rut" and doing something, anything, will "get the juices flowing" again (to mix metaphors). Ideally that would be something that productively ...



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