Search Results

Search found 4 results on 1 pages for 'meshman'.

Page 1/1 | 1 

• TDD/Tests too much an overhead/maintenance burden?

  - by MeshMan

  So you've heard it many times from those who do not truly understand the values of testing. Just to start things out, I'm a follower of Agile and Testing... I recently had a discussion about performing TDD on a product re-write where the current team does not practice unit testing on any level, and probably have never heard of the dependency injection technique or test patterns/design etc (we won't even get on to clean code). Now, I am fully responsible for the rewrite of this product and I'm told that attempting it in the fashion of TDD, will merely make it a maintenance nightmare and impossible for the team maintain. Furthermore, as it's a front-end application (not web-based), adding tests is pointless, as the business drive changes (by changes they mean improvements of course), the tests will become out of date, other developers who come on to the project in the future will not maintain them and become more of a burden for them to fix etc. I can understand that TDD in a team that does not currently hold any testing experience doesn't sound good, but my argument in this case is that I can teach my practice to those around me, but further more, I know that TDD makes BETTER software. Even if I was to produce the software using TDD, and throw all the tests away on handing it over to a maintenance team, it surely would be a better approach than not using TDD at all from the start? I've been shot down as I've mentioned doing TDD on most projects for a team that have never heard of it. The thought of "interfaces" and strange looking DI constructors scares them off... Can anyone please help me in what is normally a very short conversation of trying to sell TDD and my approach to people? I usually have a very short window of argument before falling at the knees to the company/team.

  Read the article

• At what point would you drop some of your principles of software development for the sake of more money?

  - by MeshMan

  I'd like to throw this question out there to interestingly see where the medium is. I'm going to admit that in my last 12 months, I picked up TDD and a lot of the Agile values in software development. I was so overwhelmed with how much better my development of software became that I would never drop them out of principle. Until...I was offered a contracting role that doubled my take home pay for the year. The company I joined didn't follow any specific methodology, the team hadn't heard of anything like code smells, SOLID, etc., and I certainly wasn't going to get away with spending time doing TDD if the team had never even seen unit testing in practice. Am I a sell out? No, not completely... Code will always been written "cleanly" (as per Uncle Bob's teachings) and the principles of SOLID will always be applied to the code that I write as they are needed. Testing was dropped for me though, the company couldn't afford to have such a unknown handed to the team who quite frankly, even I did create test frameworks, they would never use/maintain the test framework correctly. Using that as an example, what point would you say a developer should never drop his craftsmanship principles for the sake of money/other benefits to them personally? I understand that this can be a very personal opinion on how concerned one is to their own needs, business needs, and the sake of craftsmanship etc. But one can consider that for example testing can be dropped if the company decided they would rather have a test team, than rather understand unit testing in programming, would that be something you could forgive yourself for like I did? So given that there is something you would drop, there usually should be an equal cost in the business that makes up for what you drop - hopefully, unless of course you are pretty much out for lining your own pockets and not community/social collaborating ;). Double your money, go back to RAD? Or walk on, and look for someone doing Agile, and never look back...

  Read the article

• How to start a Software Company

  - by MeshMan

  I've always been interested in wondering how software companies happen. I find it extremely difficult once you're tied down with car, house, life etc. Funding is always the biggest concern. To make this a bit more specific, I see two types. Those offering a product/service or those offering a consultancy company. One things that bugs me about the product/service kind is that we all know how burning the candle at both ends is extremely exhausting. Coding for 8-10 hours in the day and then code in the evenings on your own stuff, doesn't last long. No matter how passionate you are about your idea, simply put, coding day and night is a recipe for burn out. Is this a defeatist attitude though? Can it be balanced? A consultancy kind isn't as tricky in my honest opinion. I think once you have spent years and years in the industry building up relationships, contacts from contracting or moving around, and of course, being involved in the community, then landing your first project as a consultant I'm sure is easier than the product/service kind. I'd imagine friends then could join you as you take on bigger company projects, like an Agile implementation or TDD training, then off you go gaining bigger things. Could you please specify which company type you're answering if you can't contribute to both. I'd like to hear everyone's experiences or ideas on any level for software company start-ups.

  Read the article

• Contractor - Mispaid again - Walked out

  - by MeshMan

  Hi all, I'm wondering whether or not I've done the right thing as a contractor. Basically I'm in to my 3rd month, and my current client messed up the payment in the first month, and I just found out that they are again late in paying me for my 2nd month. It wouldn't be so bad if I wasn't in a bit of a financial situation due to this being my first contract experience. But as a matter of principal, I walked out on them and will be telling them that I will not be going back in until they resolve the pay. Part of me feels as though this was not a very professional thing to do, but I also don't feel that it was very professional for them to mess my payments up, twice in a row. Did I make the right decision? I still want to work for these guys and enjoy the job, but I have a life to attend to that requires finances and I can't afford to keep getting messed up with pay like this. I attempted to phrase the question to be oriented around contractors behaviour around clients that mis-treat them, and as some of the answers that have been posted so far, it's a good discussion. The answers coming in are great around different subjective situations.

  Read the article

1