I just recently left my last job, and they supported it quite heavily. The applications were extremely old. I avoided it as much as possible, but the little I did learn came down to you could replace the entire system with web services, of one flavor or another, and make life very easy. If I had to explain it to somebody who had never seen it, I would say .Net Remoting was the grandfather of web services, before anybody know what web services were. One of the many problems that we faced, in working with Remoting, was the code had been built in Visual Studio prior to 2005. That was our guess anyway. We didn't have any licenses for an IDE that would work on it, and it was next to impossible to make changes. The programs that used it were on a 6 months cycle that lasted 3 months. They ran data in March through June and then again in September through November. That left us only 3 months to rewrite everything before the software had to be ran again and it was a fairly large and complex system. In general, dealing with it sucked. I don't know the final outcome but the program was on the board for a modernization to using web services.

I have to agree with the developer and I don't believe this is perfectionism. I have a distinct feeling this is experience and being burned a few times. The specifications you are providing, to me, don't sound fully flushed out and it sounds like there are a whole lot of truly unreasonable expectations of both people and the final system. I am left with two conclusions, either you are building a prototype to demo to reinforce the requirements, in which case the developer SHOULD NOT BE DEVELOPING, or you don't have a full understanding of how systems and people usually function and you need to be looking hard at your expectations. Call me a skeptic but your stated requirements break down like this, you have someone who wants to create data, never read it, will always input it correctly and always have whatever that data is follow through perfectly. That is what you are describing. From CRUD you are stating is that the data will only be created, well that means you don't need the read to verify the input was correct. You don't need the update because their data will always be input correctly the first time, and never need alteration. The data will always be followed through on (i.e. I have a store and every order ever placed will always be completed and never removed). Unfortunately, none of that sounds true. It sounds more like the specifications aren't fully flushed out and you are prototyping a product that is not whole. I have seen this, and I may not be exaggerating here, a million times but when you start the sentence off with I have this data, it literally means, I will tell you I don't need CRUD but in reality I do, I just don't realize it yet. I will the day before we launch. In nearly 20 years, I have yet to hear of a system that never needs all of the parts of CRUD. I have bumped into systems that don't need the delete part, but even those are rare.

When I studied for my computer science degree, it was all about computer science. When I studied for my business degree, it was all about business. The concepts of this post are a lot bit of both. When I look at this post the first thing that comes to my mind is, how long does your code base need to survive? Are we looking at an application with a lifespan of 5 years, 20, 30? I do a lot of government work and see the last two numbers quite a bit, whether by planning or just the arena. I will focus just on the 5 years. Name a technology that was the new thing 5 years ago, is it still around? If you based you new application on it 5 years ago and it is, great, but you still have to rewrite as you are now at end-of-life. If the stack isn't still around, now you have a product that has either been rewritten a couple of times, or is in sore need of a rewrite now. What is the cost of that? What is your ROI? TCO? Basically what is the true cost of using that stack for 5 years. That is the business end of it. Developers, we tend to look at, oh here is a new shiny toy and I want to use it. Meanwhile your boss is saying, no it will be too expensive. "Keeping up" is a game of chasing the shiny new toy, regardless of business cost. Short term that may be great, long term that can be very expensive. Always "keeping up" HAS a significant cost to a business. Not having a stable framework for more than 6 months, HAS a significant cost. Always "keeping up" can be so expensive that a company goes under for no reason other than "keeping up". I have never been a person willing to follow the trends. I find a stack that works, can be maintained and will last a significant amount of time, and use that. I mean seriously wasn't Ruby on Rails supposed to completely change our industry (switch this out for one of hundreds of trends)? To me the whole concept of "keeping up" smells of a junior or mid-level developer who hasn't stopped and stepped back, to look at the picture of a whole business and ONLY cares about code. Without a business, there is no code, if chasing a new shiny object can't support a business, it shouldn't be done period. Moving to updating frameworks and code in a way that supports a business and is done in a cost effective way, is what a senior developer should have in his mind. You have to support the business and they will support you.

I converted to Microsoft's framework years ago. I believe it was still alpha, at the time. I absolutely love it. I was also trained on Java Servlet Pages in school and these used the MVC pattern and I quite like those. I have developed WebForms applications and WinForm applications as well. MVC, in any form, is a tool and you have to understand how, and where, to use it. For the vast majority of my development, it is the perfect tool. The conversion from WebForms took a bit, but once I invested the time I wouldn't return to WebForms unless I had to.

The last time I looked, Xamarin doesn't produce XCode or Java directly, that makes it hybrid. Xamarin may produce native code as an output but it still isn't what I would consider native development. Similar points is that .Net code doesn't run on any mobile device that I know of. You produce the code in .Net and then it outputs what is needed for each of the different platforms. I am pretty sure that is the definition of hybrid development. Of course, maybe I have been wrong about the definition of hybrid development for years now.

I have worked on hybrid development before. The project was scrapped before launch as being not needed because the company had a mobile friendly website. This was before Xamarin was more than a beta. I looked at Xamarin as a solution then and didn't like. I have gone back recently and really don't see much that would change my mind. Unfortunately, some of the better hybrid solutions have died out and really, for Visual Studio, Xamarin has become the only option. Personally, if I had to choose between Xamarin and having to learn native development from scratch, I would go native as Xamarin just seems half baked and overly difficult.

First I must mention, why would you not include the Chronic Idiots? The Chronic Idiots are the first, and most important not to get along with. Granted that goes without saying, but now you have offended them. :) I think this depends heavily on definitions, particularly how you define getting along. If getting along with people means being nice to them and treating them fairly as possible, than I really do believe that you should try to get along with everyone. If it means not tolerating their crap, calling them out when needed and not letting them slack off, than yeah you won't be getting along with everyone. My current job aside, I usually like everybody I work with, and usually develop several lasting friendships at each job. There are always people who, for one reason or another, I actively avoid but when I have worked in a good job they are usually limited. If I was forced to deal with them, I would be as patient as possible with them, but it would be like nails grinding on a chalkboard the whole time. In general, would be highly tiring and trying all at once and I would not like doing it often. My current job, however, is very different. I highly dislike my boss. He was a medium level programmer, with a fair amount of skill, promoted to management who never should have been. He is a horrible leader, a horrible manager and a worse boss. In his current position he quite literally has no redeeming qualities. He has started to stack the department with only people he likes and has known in other jobs, passes all the good assignments to them, and has begun to develop a cult of personality following him that neither challenges his bad decisions, or would be willing to even speak up. And the list of really bad decisions, well, that list is gigantic and some of those have cost a significant amount of money lost. Currently, I don't get along with him or anybody he has brought along. That being said an obvious question comes to mind, why would I continue to work there. A long story short, I usually decide to change jobs every three to five years depending on projects, future and a lot of other factors. As an example, I had one job that the project manager left right after a big project and for the next 9 months we couldn't hold a project manager and had no work. I get really bored with nothing to do, even though I was still getting paid. I have never had a truly horrible boss till my current one though, and I was considering finding other work his first week, but I wanted to make

I think the degree is absolutely worth it. From my point of view, the specific information will rapidly become useless much as the carburetor knowledge, but the base knowledge what does it do, how does it function, how to troubleshoot it, how to dismantle it still remains relevant permanently. There are certain things you get from an education that you simply can't get anywhere else. The largest problem I run into on the job is that many, many, people I work with simply cannot reason out how to fix a problem. I learned how to troubleshoot in school when I was about 10, learned to apply it to cars at 15, learned to apply it electronics in my 20's, learned to use it on tanks in the military in my mid 20's, and finally applied it to computers and software in my 30's. The steps are all the same just the thing you are working on is different. If everybody could learn that the world would be better. What I already knew was reinforced in my computer science courses. Many of the much younger students were just learning it. That is just one example. I currently can program in about a dozen languages proficiently. I have forgotten how to program in at least 4 simply because I don't use them and would have to relearn them. I was only taught 2 languages in school, but because my education worked through the basics and taught me how to read them, I learned I just applied that to a new language and I could learn it in just a few days. Without that, I would have to struggle for much longer. The reality is there are just basic fundamentals that you get in school that you can learn on the job but school, if you push it, can be done in 3 and a half or four years. If you try to learn everything on the job it will take at least twice that. I have known a lot of developers that are self taught that can program extremely well but if you have them say design a database, they botch it horribly because they never learned database principles. With all of that being said, if I had to take a programmer fresh out of school with a masters degree, roughly six years, or a self taught programmer with six years of experience, I would have to really think about it. There is a lot to be said for experience. If I had to take a new developer out of school or a developer who is going to coding boot camps and trying to teach himself, I would go with the new graduate. They come with basic fundamentals and can learn faster in my belief. As for the debt, the boredom and all of the arguments against school. Stop already,

It is interesting, I am actually okay either way. I usually tend to do cowboy coding if it is a smaller or a personal project but if it is slightly larger or if it is a work project I think having more details makes for a more successful project. As software developers, we are used to having things change and shift and not really be locked down, but our customers tend not to be really comfortable with that, especially depending on the industry. I find most customers need a firm set of dates when things will be available, what they will cost and the level of effort things will take. You can't really give them that without having a significant amount of detail.

Quote:

Exactly my current situation. There's two things I can do: bitch about how nothing is clear and we're all wasting effort or trying to figure out what needs to be done and make the best of it. I'm going for the latter, with the side note that I actually like working that way as talking to people and figuring out specs is a welcome change from programming

This is pretty much my thinking, for the most part, on not having things spelled out. I am pretty able to go with whatever is going on, but I really hate wasting my time and effort even though I get paid either way.

I agree with some of the posters. I have seen quite a few methodologies and the frustrating thing I see, especially as it relates to agile, is that everybody believes it solves all software problems but they don't really understand what they are. Agile development is a method of development of software, not a method of everything. As an example, if I give you a cow and a tree and tell you to build a teepee, you end up short of a few things. How do I get cow hide? How do I get poles? How do I build the teepee? Do I have to fit it for one person? Yeah, that list could go on forever, but I think it makes the point. You have to do the basics. You have to do the analysis. You have to do the requirements gathering. You have to define testing, if you want to test? How? Unit testing only? Again, that list can go on forever. In my experience the industry, and quite literally every job I have worked at in a decade, goes "we are doing agile application development, here is the customers old database it is 20 years old, you have to build a new modern database from it. You also have to modernize it, use all these new technologies and make it shiny. Oh and you can't talk to the customer." They then expect agile to just cover the development, not have any problems and make a perfect product without even finding out what the clients current needs are. It is ridiculous and it shows how the actual concepts of software development are dying to a culture of fads and not actually using the thing between your ears.

I have the strong inclination to split some hairs here but I think it needs to be said. In your two scenarios you are talking about two very distinct things, neither of which have anything to do with AGILE. That happens to be the hair I am splitting. There is a highly important second word that the community has a nasty habit of leaving off when referring to "agile" and that it isn't "agile" it is "agile development". Like I said, a bit of hair splitting but important. Regardless of using agile, waterfall, or whatever; you have to have some basics. You have to have requirements (agile ends up using these to come up with the user stories, or a bunch of different names), waterfall uses this as requirements and etc. through other methodologies but they have to exist first. Where this comes into your two scenarios is in the first, the questions that are being asked are being asked because the requirements are incomplete and unclear, in the second the requirements are not complete but this fact is being ignored. Agile is supposed to make it easier to develop and handle requirement changes but the community seems to accept, at least in my encounters, that agile is actually designed to allow us to not have all the requirements, and the ones we have not be complete, and we develop without them. In practical experience what this leads to, at least in my experience, is the first method will ensure that the best application possible comes out in the alpha, beta, or whatever, with the minimal amount of time involved in basic things like layout and page views; the second method is going to result in a large amount of time spent in tedious things like altering a page layout a half an inch so one text box lines up with another, and repetitive views and things like this. I just wrapped a project, as an example, where a page had a registration form and nobody laid out the requirements and by the time we got close to the end, the one view, a simple registration form had been re-done seven or eight times with the irony of the me pulling up the original page and the final page and everybody realizing that the original and the final were exactly identical but we had redone it seven or eight times. The first reminds me of someone understanding a real development process, be it agile or whatever, and the second being cowboy coding with no regard to thinking things out, wasting effort or repeating work.

I had Lasik surgery a few years ago and my vision has always been 20/10 since. I noticed a couple of years ago that spending all day working on a computer was making my eyes really dry and I had trouble seeing highway signs going home. I went to the doctor and they set up regular glasses with anti-glare coating to roughly fit my work environment. They are really interesting because I can wear them fine when I am on the computer but if I look away or stand up and try to walk everything is blurry and off. They did fix the vision problem at the end of the day. I leave work and everything is perfectly clear. I still suffer from dry eyes though, so I have to use eye drops. Unfortunately, I have never had a job that covered the cost of glasses very well so I usually end up spending $250 or more whenever I need a new pair.

In my opinion, there are some who have danced around the concept of patterns and some who have missed it entirely. Patterns, be it concepts from the Gang of Four or from Martin Fowler, are by their very nature language agnostic. I saw mention of compensation for problems with Java and lots of focus on specific languages in the comments, but that wasn't ever the intent of Patterns. Patterns are there to make tasks that are repeated, code heavy and reusable to be easier and somewhat normalized, that is pretty much it. I think the most important comment I saw mentioned KISS. That is the biggest key concept when dealing with Patterns to me. If you are building a basic application and adding hundreds of lines of code to use a Pattern when you need 5 lines, that isn't what a Pattern is meant to do. However, if you are building an application that is data heavy and needs lots of database interactions, there are many patterns that can make this easier and quicker to code than not. Some of using Patterns is opinion, some of it is knowledge. I know from when I was starting out, I didn't use a lot of them and mostly avoided them. I find I use them more so now but I use them only as the situation really needs it. I often find that I will use a Pattern when other developers don't/won't/can't as well. They are not easy to implement all the time and experience is often needed to make them work well. Definitely my opinion but they can be worth it if used right.

Okay, maybe I am insane, but I have never gotten why people have problems with branching/merging whether it is with TFS or GIT or whatever source control. Early in my career, I think 10 or more years ago, I read a white paper from Microsoft on the best practices for handling version control branching in TFS. This may well have been before GIT even existed. The paper was clear and concise, left multiple choices on branching/merging strategies and how to handle conflicts and other problems in source control. As far as I know, that white paper is still out there and available and even though it is old now, it is still very relevant. I read it once, reviewed it a couple of years later and I haven't had a problem with source control since. Everything made sense and it has always been easy for me. Like I said, maybe I am insane, but I encounter many developers that can't handle branching/merging and conflicts and I truly don't get the problem. Maybe you guys can clue me in.

Random comments first, I think the "MVC 'was dead'" comment is funny and completely ridiculous. Whomever told you that is the first person to stop listening too. Second, the compile to JavaScript idea just about as funny. MVC, WebForms and compile to JavaScript are all current and usable technologies. Now useful advice, I know you said no CMS but this is probably going to be something to reconsider. You need one that is lightweight and easy, that is unless you want to be doing updates all the time. I find when I am asked to do this concept that it involves initial build, hosting and the usual but then continues to need updates on a regular basis. It is a bit the nature of websites to constantly change. If you really want to stick with no CMS, then I agree with some of the other comments, you need to find something that offers a good, customizable cookie cutter template and use it to build the site. You need to find the easiest way to build something nice and something easy to update. I think somebody mentioned nopCommerce and that may be a good way to go. There are many other systems like them out there. If you do need shopping cart and e-commerce capabilities then you are getting into a whole different mess. Depending on volume and software, you may now have to worry about PCI compliance, so you probably want to use a third party to process payments so you don't have to worry about that type of information. There are a large amount of considerations depending on the site needs. I would lay everything out and make sure to pick the easiest to use and maintain software.

I also use SmarterAsp.net. I use webhostforasp.net as a secondary provider. I received free package deals for both and have kept them around because why get rid of free, but that was back when they were just starting out. I have had good luck with both of them. Easy control panels, easy to load sites and fairly easy to manage. I would recommend you look at Azure as well. I wouldn't look in any other direction if you are using a .net application as you will probably have too many problems maintaining everything. That is my practical experience, anyway. The problem I have with all of the Cloud solutions is the true hidden cost. If you purchase a hosting account through one of the providers above, you get x space, with y sites, with z databases and everything is spelled out. The last time I looked at Cloud solutions you get some of the same but some of the billing is based on usage volume, number of Mbytes written to the disk or along the lan etc. Before recommending either or choosing a direction, I would see if you could get a true hard fixed, per month cost. That may help. Your client isn't going to care about "if I use this much volume in March, it costs $100, if I use this much volume in April it will cost $200", they are just going to be pissed when their bill doubles. Plus, I have a golden rule that I always use for applications, and that is they will always grow. If you are only using a little bit now, give it a couple years and that will be significantly larger.

PapertrailApp might work great but that assumes an extraordinarily large amount of things that are, in my opinion, not true for most organizations. The biggest assumption is that the organization wants any of their information, logs or not, going to the cloud. There is a lot of data that should never leave a DMZ. The second is that there is a case for aggregating all of that data together. Depending on the organizations needs, much of what PapertrailApp will do is just straight overkill. Loggers like log4net and nlog are simple, easy to configure loggers that make rapidly building an application with some tracking and logging quick and easy. I am not saying PapertrailApp wouldn't do the trick but don't hit a tiny nail with a sledge hammer, it never ends well.

I rarely feel a need to comment but I had to jump in on this one. Please understand, I am not excusing Microsoft and Visual Studio does have some problems and flaws. In this case though, I doubt Visual Studio/Microsoft is the complete problem. You are correct about some delay, it should be about 1 to 10 seconds and no more, and that is on my development machine. The machine is running 16G ram with a quad core processor at 3.6G. That is my work dev machine. My home dev machine is about half that and is at least 6 years old. My home dev machine has the same delay time. The problem I suspect you are encountering is with where you working directory is located. I used to encounter this problem when the default working directory is set to a location that is, in reality, a networked drive. This is a common habit at most work location as the average use is set so their personal working folders go to a networked drive where it is backed up into the corporate backup. At least in my experience that is common and how most work computers are set. When you do this with Visual Studio, which uses the default Documents folder, for its default working directory you end up compiling all of your resources across a network and through a network drive. I have, and I mean for years, found I get your exact same problems whenever this is the situation. As such, I moved my working directory to the local hard drive and the problems go away. My standard when I set up a development machine is I move all my development to C:\Development for a folder name. Within that folder I have the year of Visual Studio I am using, i.e. 2012, 2015, 2017 or whatever, than each project in the year. It is easier to organize locally and easier to find everything. If your problem is what I think it is, than it should also eliminate the really slow drag you are seeing and the false starts. Like I said, this is just what I suspect is the problem but it is what I usually run into. I am also not excusing Microsoft. It is a really stupid problem to have and it shouldn't be an issue but it does seem to be. Try moving where the applications are for just one, as a test, and you can see if it is worth changing all of the settings in the option menu.