Tag Info

Hot answers tagged

75

An attitude of never using third-party libraries is preposterous. Writing everything yourself is a horrible use of your company's time, unless there is a strict business requirement that every line in the codebase was written by an employee of the company -- but that is an unusual scenario, especially for a private-sector firm like you've described. A more ...


61

This is a symptom of a wider migration towards distributed version control systems. Some websites which traditionally hosted non distributed VCS (eg Codeplex & SourceForge) were a little slow in adding support for DVCS (eg Git or Mercurial). So, people who wanted to use DVCS for their project were forced to migrate their projects over to the providers ...


48

The situation warrants an analytical approach to the decision. The bottom line will be "Does the CASE tool provide a value to the business?" Often, management will want developers to adopt a methodology or tool because they have heard good things about it, regardless of how well it fits into the current processes and culture of the organization. If your ...


47

Code reviews are a great practice. It is probably the best way to learn from mistakes and to see how certain problems are solved by others. It is also one of the best way to maintain quality in a code base. Code reviews happen in many companies, though it is difficult to say that there is a specific process that they all follow. In more formal code ...


41

My question is: am I too harsh on this matter? You can lead a horse to water, but you can't make him drink. It's hard to say whether you're "too harsh," but it may be unrealistic to expect your teammates to adopt all the infrastructure that you're hoping for. And truly, if the team is working well together, using a wiki to communicate between three ...


34

That seems incredibly uncompetitive. I've worked in shops that decided to skip the standard open-source libraries like Hibernate and roll their own due to some "critical" missing feature. In the end the software was incredibly expensive to build and maintain. Of course the expense of the in-house library was grossly underestimated. And while the in-house ...


31

One of the Great Myths™ of programming is that there are clear lines drawn between Architect // Designer // Programmer // Coder. This was, and is, bollocks. The process begins with the customer saying, "I need ..." and ends with them saying, "Yes! That's what I wanted!" And you don't get to the end without a lot of tweaks / changes / massive-rewrites of the ...


30

Short Version By adopting Zed Shaw's Programming, Motherf*cker! methodology? Longer (Serious) Version While Shaw - despite being a bit overly enthusiatic and (way) over the edge - definitely has a point there, there's a bit more to it than that... You quite simply need to learn to embrace something similar to a personal productivity ritual or ...


28

Project Hosting is Infrastructure. Infrastructure exhibits Network Effects, which means that Infrastructure gets more useful the more people are connected to it. (In particular, the usefulness is O(number_of_connections), which means that for any individual member it is O(total_members) and for the whole system it is O(total_members^2)). This, in turn, leads ...


27

Yes you should. Because you need evidence to back up your assertion that they won't help. You never know, you might find that they will help. Because your employer told you to. I won't repeat the points laid out by David Kaczynski in his excellent answer as they are exactly the steps you should follow.


26

I can point you to Alistair Cockburn's thoughts on this aspect of 'true' Agile projects: One member in the Crystal family of methodologies is Crystal Clear. Crystal Clear can be described to a Level 3 listener in the following words: “Put 4-6 people in a room with workstations and whiteboards and access to the users. Have them deliver running, ...


26

I would not expect any "agile development process" here as a solution to your current problem. First thing for you should be: clear your mission. That means: clarify what your own responsibilities are clarify what the responsibilities of the other stakeholders are identify who is responsible for each of the legacy systems if there is no client (yet) for ...


21

Does software testing methodology rely on flawed data? Yes, demonstrably. Examining the Agile Cost of Change Curve shows that part of Kent Beck's work on XP (I'm not sure whether it was part of his motivation or his justification) was to "flatten the curve" of defect costs, based on knowledge of the "exponential" curve that lies behind the Code Complete ...


20

My attitude is that if you can learn to do these things on small projects, you'll be prepared when big projects come along. If they follow good development practice with this project, they will have code to showcase to future employers, and they will have experience that would make them valuable as employees. If you want more material for convincing them, ...


20

The shop has a disease called Not Invented Here. It is a good reason to terminate the interview on the spot and leave immediately. This can only be cured by a top-down house cleaning that is very unlikely to happen. To answer your question, it is sadly much more common than you might think and it's definitely a reason to be concerned.


18

I used to do exactly the same thing. Then I discovered test-driven development. Far from believing that TDD is a fix-all for everyone, I do think it works for people like us, who think most naturally in code. For me, TDD serves a number of purposes: It allows me to dive straight into coding, while I'm thinking. It allows me to design at the same time as ...


17

More important than filing a bug report is to create a test case that will trigger it. If it takes only two minutes to fix a bug, how quickly would you forget about it? Create that test, fix the bug, and it won't raise its ugly head again. The test case is a living bug report, in the sense that no-one has to browse through a bugs database to evaluate what ...


16

Take the long term perspective on this issue. A lot of the items you mentioned wash away when you place a lens of objectivity over the situation. You've got minimal skin in this game and no real desire / prospects for significant contract work from the NFP. Ultimately, what benefit is there to you to answer one way or the other to the management request? ...


15

If your comments only look like this: /// <summary> /// Gets or sets the sublot number. /// </summary> /// <value> /// The sublot number. /// </value> Then yes, they are not all that useful. If they read something like this: /// <summary> /// Gets or sets the sublot number. /// Note that the sublot number is only used by the ...


15

Should developers be worried about possible automation happening in their projects that might make them redundant ? I never particularly worried about this myself but I have seen many developers worrying about it, even if they don't admit this openly. There is a fear that if you automate most of the aspects of a system that you are handling it ...


15

Yes, definitely be concerned! That reeks of arrogance and (sorry to be harsh) stupidity. Any programmer with half a brain will use a library like signalR instead of writing it yourself. There is absolutely no point in wasting your time solving a problem that has already be solved. I would possibly try to find out more information first - they might have ...


14

"Normal" Keep in mind that sales teams are there to ... sell the product you wrote. They are naturally adapting to client demand and selling features that their (and yours!) clients need. You actually want them doing this; it means that revenue is coming in the door and that your product is staying relevant to market needs. I'll note that this can be ...


13

Code reviews are very useful tool for learning, especially when you have new team member on-board. Well, it is also known as peer review process :) There are different types of code reviews: Over-the-shoulder – where one developer looks over the code author's shoulder as the latter walks through the code. Email pass-around – Source code management system ...


12

I think you are getting a bit both anxious and excited at working for a group. None of us learned working in a group or team from books or was given any baby steps or "Dummies Guide to Working in Teams". We just learn working WITH groups by working IN groups. Everything that you heard about professional programmers, will fall into place gradually as you ...


12

There are plenty of sources to learn from aside more experienced colleagues: books, blogs of skillful developers, Stack Exchange, lectures/conferences, etc. Code reviews are also crucial, and CodeReview.SE is a precious resource. Let's see how it could work on an example. Example You're reading a blog post which mentions a term "ETL". You don't know the ...


12

I'd embrace the metaphor and simply point out where normal bridge building practices differ from normal software development practices. The requirements of the bridge are defined well in advance and do not change during construction. No one thinks about moving the starting or ending point of the bridge midway through construction. No one expects a road ...


11

By asking this question you are basically underlining the fact that the project in question is indeed important enough to justify a contract. Really, all projects where money is involved, and even some where it's not, need a contract. Drafting a basic contract which covers the scope of delivery and payment is probably less work than devising and ...


11

Here's one possibility as to why this makes such a difference. This experiment hit the media a few months ago: Study: Walking through a doorway wipes out memory It talks how a doorway acts as a sort of mental reset button. Most people have had the experience of walking into a room and forgetting what they came there for. The controlled study shows that ...


11

I've never seen a formalised, standardised way to do this - but I've seen two common patterns. Feature Ownership - each developer takes exclusive responsibility for a particular feature of the system, and implements this through all appropriate layers. Key Advantage: one developer, with a full understanding of the entire feature, can work through all ...



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