Tag Info

Hot answers tagged

110

Automation. When you are developing, only in the most simple projects will the default "build" button do everything you need it to do; you may need to create WS out of APIs, generate docs, link with external resources, deploy the changes to a server, etc. Some IDEs allow you to customize the build process by adding extra steps or builders, but that only ...


80

You need a proper Quality Assurance (QA) process. In a professional software development team, you don't push from development right to production. You have at least three separate environments: development, staging and production. When you think that you got something working in your development environment, you push to staging first, where each commit is ...


47

If all you have is 2 days and no time to prototype or even read upon all the alternatives then there's really only 2 options: ask someone who knows and follow their advice. This may not necessarily mean asking an individual but spend the 2 days searching through blogs and articles to glean enough information to make a slightly-better-than-uninformed ...


47

You will probably want to get a dev server, and preferably a staging environment too. Nobody should ever be pushing from local to production except for their own personal website. Your deploy process should only support dev->staging->prod. You probably want someone responsible for signing off new releases - depending on the organisation, this can be a ...


41

This is a conversation you should be having together, discussing the requirements and pros and cons of different formats. If one side or the other is dictating what happens, you're going to end up with bad software and an unhappy team.


30

Like code, a build script is executed by the computer. Computers are exceptionally good at following a set of instructions. In fact, (outside of self-modifying code), computers will execute the same sequence of instructions exactly the same way, given the same input. This delivers a level of consistency that, well, only a computer can match. By contrast, ...


28

You've written down a few pointers for them, but you haven't explained why is your approach better than the one they already use. This may be problematic. If you're in a spirit “We'll do it my way, because I have six years of professional experience, and you don't” (and reading your question, it looks exactly this way), be ready to be hated by your team ...


19

It may seem that I am going against the stream, but I have recently read the book Creativity, Inc. by Ed Catmull and there was a really nice paragraph tackling this situation: Andrew Stanton spoke next. Andrew is fond of saying that people need to be wrong as fast as they can. In a battle, if you're faced with two hills and you're unsure which one to ...


17

At work, we avoid this by using Gerrit. Gerrit is a code review system that acts as a gate to your main/production Git branch which is conventionally called "master". You have code reviews, right? It sounds like you personally do them exceptionally. With Gerrit, you push to a sort of staging branch which, after you and your coworker have executed the code ...


16

For a team of 3-4 devs, you're proposing WAY too many branches. Every branch you create is additional overhead that comes with a cost (time spent merging, keeping track of what's where, etc). You need to make sure that the benefit you get from having a branch outweighs the cost. Keep in mind that the only real benefit to a branch is code isolation. ...


16

Here's an example that uses Java. It's been a while since I've used log4j, but from what I remember, the whole log4j logging tool would initialize from an XML file. The XML file itself could contain multiple loggers with different configurations(where you write to, what levels are written, etc). So, in this case you would have logger objects rather than ...


16

I see this as a largely human problem - the process is there and the tools are there, but the process is just not being followed. I agree with what others have said here, about the possibility that it's quite possible the developer in question is just stuck in an SVN mindset, and may well think that he is following the process. I find that the best way to ...


14

If all you ever want to do is <compiler> **/*.<extension>, build scripts serve little purpose (though one can argue that if you see a Makefile in the project you know you can build it with make). The thing is - non-trivial projects usually require more than that - at the very least, you'll usually need to add libraries and (as the project ...


12

I recommend the following guidelines: Involve the junior developer in your design meetings and solicit his input. This will get him thinking about the big picture, even if he is not ready to do the high-level design himself. Try to isolate and clearly define a module of the application to assign to the junior developer. Describe in writing what the ...


12

Your concerns are extremely valid. Especially the first two points about Team A not having the time to add features or fix bugs that impact Team B. I've seen this happen at my own job quite a few times. This might be a good idea if: It is known that Team A will be working on the projects that require new features in the database, while Team B's goal is ...


12

Many IDEs simply package up the commands used to build something and then generate a script and call it! For example, in Visual Studio, you can see the command-line parameters for a C++ compile in the 'command line' box. If you look closely at the build output you'll see the temporary file that contains the build script that was used to run the compile. ...


10

You most definetly should contribute to how the format and structure of the JSON should look like. I see it more than often that the front-end engineers, the API consumers, is the ones knowing how the data-structure should be. You are the one going to use the data, format it, loop through it and work with it. You should have an opinion on how you want it ...


10

The advertised cycle of TDD is write tests until they fail then hack at the code until they pass again and then refactor while keeping all test succeeding. When the spec changes you will need to remove the old tests that would verify a violation of the new spec and write new tests that will verify the new spec.


10

gbjbaanb makes some very good points. I just thought I'd add a bit. It's obvious you don't have enough time to make a perfectly informed decision. Your only option is to try and make a decision that will minimize future pain. I'd suggest: Clearly document the nature of the situation: Send an email to your manager(s) and CC their managers and the ...


9

Throw-away prototyping Throw-away prototyping is about creating, as fast as possible, a part of the future application to either ensure a feature is technically feasible or to show the feature to stakeholders or potential users in order to gather feedback from them. Since the source code of this prototype is not reused later when developing the application ...


9

I think your summary have over-simplified the blog post somewhat. :p I'm going to pick out three sentences, which I think is crucial as to explaining why code became... lava. The code gen system had somewhat broken down after Bruce had left. None of the remaining team really understood how it worked, so it was easier just to modify the code by hand. ...


8

Don't ask for pseudocode. If your superiors thought you needed that, they would have provided it already. Here's what you should do instead: Make your requirements testable If it's not testable, it's not a requirement; it's a feature or wish. More specifically, each individual requirement should be SMART: Specific Measurable Assignable Realistic ...


8

make is a lot easier to remember and type than gcc -o myapp -I/include/this/dir -I/include/here/as/well -I/dont/forget/this/one src/myapp.c src/myapp.h src/things/*.c src/things/*.h And projects can have very complex compilation commands. A build script also has the ability to only recompile the things that changed. If you want to do a clean build, ...


7

You mean, aside from the whole "giant production bugs leads to QA people getting fired" invested? At least in some companies I've worked, QA served as second tier technical support. They would get called alongside (or before) developers if an issue appeared in the field, since they often had a better grasp on the quirks of the shipped product than ...


7

and don't want to ask the individuals doing the work to manually record things like how long it takes them to perform a given task Here's the problem. You basically want to create meaningful metrics, without measuring the only thing that matters. Nearly all of your users won't care about how fast the code itself is unless it causes a noticeable impact ...


7

Now, how can I force them... Instead of forcing your colleagues, try making them see things from your perspective. This will make things much easier for everyone. Which leads me into... I want this behavior to be punished in some way or make it unpleasant as much as possible. Why is it a pain for you with problems on the live server, but not for ...


7

This is not uncommon, particularly in small teams. Don't make a big deal about it, but make an informal rule: Break the build, bring in donuts. Either 1) You'll get donuts twice a week or 2) they will adhere to the standard. Bring it up in a meeting. Not accusingly, don't mention anyone by name, but something similar to, "Since we introduced version ...


6

One strategy, which can be established with any decent VCS, is to open a parallel maintenance branch in such a situation (based on the latest stable production release) and merge only the immediate bugfixes or other urgent changes for production into it (for example, the changes of your developer B). Typically, you can create a maintenance release from this ...


6

Short answer: No. Longer answer: If your refactorings are truly improvements, then you're engaging in Codependent behaviour - you're supporting your collaborator's bad habits & not giving him/her the opportunity to improve. If your refactorings are trivial, then you're probably wasting your time and/or risking the possibility of falling into an edit ...


6

Several ideas. Although I am not very sure how generally applicable they are. First, in a lot of articles that reference this anti-pattern, the first advice is to resist the urge. One way to resist the urge is to understand the Dunning Kruger effect, and to spend time exploring whether the urge to refactor could have been influenced by the lack of ...



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