It's a simple equation with 3 variables : time (and implicit money), set of features/bugs ratio and code quality. For best results the trick is not to overemphasize one over the remaining 2 and just keep all 3 balanced. Sounds simple but sometimes it feels like the hardest thing in the world.
Non functional requirements are just as important as functional ones. Yet not much thought is given to them (especially at the beginning when writing the specs for a new "system"). For instance everyone, obviously, wants a secure application (also security is a bool, it's either secure or not, there are no intermediary steps) so a new application will not be released if it's insecure no matter how many functional requirements are implemented.
The idea is to always keep in mind non functional requirements when designing a new "system". Some of the non functional requirements (like capacity/performance or security) can even have a direct impact over the functional requirements.
One of the new C#6 features is string interpolation (which makes the code much nicer than using string.format()) . But by default the new Roslyn compiler is not used when compiling the MVC views. You can change this by installing the nuget package called Microsoft.CodeDom.Providers.DotNetCompilerPlatform
Ah, the build + optional deploy script. The "thing" that turns whatever your compiler spits out into a zip/msi/whatever that you can actually install /pass along to customers. For build scripts i've started with batch files, C# , Powershell, moving to msbuild tasks (yeah, that was "fun" ), FAKE, to the node.js "task runner" framework du jour (Grunt, Gulp etc) to finally get back to Powershell.
I still think the best solution for writing a build script is in a shell scripting language (Powershell, bash, whatever) because :
- when it will crash (and it will !!) you're debugging code written by you instead of fuzzing around with a stacktrace spitted up by some shitty Grunt plugin (for instance).
- ubiquity : only powershell/bash is required to run it (compared with node.js + npm + gulp + whatever other plugins you are using).
- simplest way to run 3rd party CLI apps as part of build process ( "& filePath args" and you're done).
- everything is in one place (no package.json, gruntfile(s) and so on). A single file that handles everything.
I ask this question pretty often to my fellow colleague developers. I'm actually very interesting to see how exactly they perceive the work they do. Most of the time i get back the boring (and untrue) "engineer". Most of the people "doing software" seem to think they are engineers. This can't really be further from the true (if you don't believe me, you should speak with a "regular" engineer from other areas and compare your work with his/her).
Another category of people think of themselves in more abstract terms : poets (because writing code is exactly like writing poetry, right ?) or even philosophers. Obviously, this is bullshit....
Other people think of themselves as craftsmen (personally i think this is a lot closer to the truth). At the end of the day, personally, i think building software is a lot like regular craftsmanship.We use tools just like other craftsmen (instead nails and hammers we use IDEs and debuggers) to "craft" something. The result of our work is , hopefully, something that other people enjoy to use.
What i don't understand is why do people get upset when i told them there isn't much of a difference between what they do and people who build chairs...