Tag Info

Hot answers tagged

233

You're not any slower in completing projects. Previously, you thought your novice projects were done when they really were not. You should sell this quality to clients. "This company might get it done faster and cheaper, but is it really done? Or will you be hunting bugs for years?" Beyond that, you need to know and accept the old idiom: "Perfect is the ...


153

Sounds like it's time for you to join the dark side: management. I'm not suggesting you give up programming and become a manager. But it seems like all the experience you've quoted up until now has been technical in nature. In simple operation of writing out a file, you can think of 10 different aspects that a less mature developer would never consider. Not ...


76

I had the (likely) same problem many years ago, it lasted for a few years and I overcame it. So maybe it would be of some interest to you to know how I achieved that, even if I'm not sure my way will also apply to you. You should also have a look here : The Seven Stages of Expertise in Software Engineering It shows that productivity is in great part a side ...


35

An important part of programming is managing and controlling complexity and for me personally, it is one of the top issues. If ignored then either the frequency of deficiencies surges or, as in your case, the ETA of finished software increases dramatically. Software complexity can be controlled and managed from many different levels and ways but a good ...


23

The simple answer is: accept it. In all systems there's trade-offs to be made between reliability, robustness, security, speed, hardware cost, development cost, time to market, you name it. You will not always agree with how the customer makes those trade-offs, but you're not the one making those decisions. All you can do is provide a considered opinion. ...


15

The truth is that modern systems are becoming increasingly complex. The computer is now similar to that game "Jenga" where you have all of these pieces relying on many of the others. Pull out the wrong piece and you have an error, pull out a correct/necessary piece and you still may produce an error. The more complex the system the more time you are likely ...


14

It sounds like your skills would be very useful for very high quality mission critical systems development, like finance/trading related applications, broadcasting, aerospace, defense... Errors in these sort of applications are very costly and they employ people who think like you as you can cover all the cases.


8

It sounds like you're aware of your tendency to think about everything that can go wrong. Experienced Cautious Developers often learn to follow the mantra YAGNI, you ain't gonna need it, when they try to return to a lean, agile and productive workflow after getting too choked up in the weeds of failure-mode-analysis-gone-amok. However, if you are indeed ...


7

Welcome to the oft times difficult world of resourcing! The issue isn't one of Project Size vs Team Size. That's a very common misconception which often hides other problems which are usually management related. The issue is all about Scope. You need to decide what it is you can achieve with your current resources - aka you. Then you need to decide if ...


7

The success of the product / project will depend on the commitment of the company whose paying for it. If they're going to hire more programmers / support staff, there will be an inherent decrease of productivity from the one programmer, who know has to train, teach, manage, etc.. not that it's a bad thing.. but there will be a decrease before any increase ...


7

Only thing I can see is: "You are becoming more and more valuable". As and when you get more experience you learn about things you should avoid, and this is what make you better than others. One thing you would have noticed that your code would be safer and more maintainable now. Only thing you need to do is to explain your client why it took time and ...


7

when in doubt default to badly quoting Knuth... "Premature optimization is the root of all evil." Here is what I would suggest, as it seems like you have a problem that I have from time to time... What really works for me... Write the unit tests, as if all the code was done. document the interface. implement the interface. what you have really done: ...


6

I think you should stick to your coding standards, but make sure you are up-front with your clients. Many clients do not know what it takes/costs to build good software. It's part of the professional developer's job to educate them. Whether you're agile or waterfall, you get some sort of agreement from the client about what they expect the application to ...


6

Think about the practical consequences of a bug as compared to all the other problems that need solving. Consider the following consequences of creating a poorly written piece of code: Entire database gets dumped every other month. 48 hours of downtime while the backups are restored. Customer records get cross-linked. $200 worth of orders get shipped to ...


5

Your answer: Not at all I have extensive experience with both PHP and Java and I can tell you that if you know PHP well enough and you are not a total noobie and know that PHP can do classes, interfaces (and soon now even traits for horizontal reuse), exceptions, automatic class loading, etc., your PHP code can look better than Java code, and even work ...


5

I think you need to learn to decide how much needs to be done for which project. Some project may be trivial and you really don't need to spend all that time in perfecting it. Not everything is gonna need rock-solid encryption nor everything will be scaling to million users. Writing a program which can scale well for more than a million users will take time ...


5

People have developed a number of models to try to estimate things like this. While I wouldn't try to claim that any of them is anywhere close to entirely reliable or accurate, there are a few that seem to take enough factors into account to give halfway reasonable estimates. Just for one example, Barry Boehm's COCOMO II model seems to fit your situation ...


3

I would say at least 5 persons. One for test, one for spec, support and documentation and 3devs. There is a lot of things to be tested in you case, so a 50% dedicated tester should not be unreasonable. A person writing down the requirements and having customer support setting up your infra structure for testing etc should be there. Three developers I feel is ...


3

1 programmer on a large codebase with all the responsibility of configuring, testing, communicating, supporting, documenting and bug fixing isn't going to have much time for writing new code or adding features (or even refactoring old code). Break your week down by the percentage of these mandatory tasks that don't expand the business and you'll be ...


3

This is a bit controversial, but for project management SLOC is typically used for determining what the estimated timelines (i.e. read Software Estimation: Demystifying the Black Art (Best Practices (Microsoft))); however, what is usually underlined time and time again is that you need a large enough data set of similar problems you can start to notice ...


3

@Zilk, I am not great programmer and I am been programming since 1998. Even I am facing this issue now. But what I realized is ultimately quality matters. If I die today, somebody should be able to pickup what I am doing now from where I have left. Such should be the standards of programming (Universal). I have moved myself from developer to architect ...


3

The solution is to create a collection of libraries with commonly used functions which you can re-use across projects. E.g. I have a StringFunctions.dll .NET library which does stuff like encoding, encryption, decryption, regular expression evaluation, etc. This way, I don't have to continually rewrite things that don't change. Having a wrapper for file ...


3

Another option is: stop writing code, instead sell your expertise in spotting the problems in advance. In other words, become a Consultant. Many organizations are happy to pay expensive dollars (if not top-dollar) for someone to spot the issues before spending months on creating the code that makes the problems. It is well known that fixing a bug in ...


1

Just like you, I started programming at the age of 14, also when I got my first computer (although I had been studying for a few months at that point). However, I am "only" 33 now. :-) My suggestion is that, when developing something, you take each one of those worries (file permissions, number of files in a directory, etc.) and then use all of your vast ...


1

My best recommendation for you is: building blocks. Make a file building block that you can trust always, make one for your API, stop wasting your time writing the same thing over and over. Think about every problem once and fix it once and for all. Noone will catch up to that, certainly not the novice who spend 80% of their time debugging code that fails ...


1

Don't be too hard on yourself. You are working in a profession of increasing complexity, that requires more human intelligence, knowledge and experience than ever before. Computer processing power is slowing - perhaps soon stalling - leading to the need to introduce multi-core chips, gpu powered numerics, parallelism, etc. There are only so many ...


1

It will take less time to develop application in PHP, but, most probably it will not be architecturally consistent enough and, therefore, it will have more bugs. Nevertheless, cost of the change of PHP application will be lower comparatively to Java application. On the other hand, Java application will take more time to design and develop, but it will be ...


1

I'm not familiar with any formal studies regarding PHP and Java effort or productivity explicitly - most work looks at languages of different generations. I know that Java is a third-generation language, and I'm pretty sure that PHP is also a third-generation language. This says that, all other things being equal, the inherent effort needed to produce the ...


1

Time (T) required for development (of a program) is not only function of lines of code (SLOC). It's also function of quality (Q) (and probably n+1 more variables). If Q is low, then T grows somewhat linearly with SLOC. (You just bang more lines of code, and it's more or less a physical activity). When Q gets higher T starts to grow exponentially and gets ...



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