My suggestion is "Which is your least favourite phase of software development?"
My answer would be Brownfield Development. There's nothing worse than trying to add features to a software product that has no code documentation, no requirements, multiple coding and naming styles, partially adhered-to patterns interspersed with WTF hacks because certain developers either didn't understand or couldn't be bothered to maintain the inherent architecture and 70% of the original unit tests are in fact testing public static getters.
Your brownfield has unit tests??? IMO brownfield testing starts at unmodified auto-generated tests created by Visual Studio that all return "Test Inconclusive. You have to write the guts first you nitwit." or which have no tests at all.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason? Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful? --Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies. -- Sarah Hoyt
What? (I get that part with the party, but what on earth does a sheep at a Post development party?) Also, you have to consider that post development is every time you stop working, so there must be at least two or three such parties a day.
I couldn't agree more. You'd never dream of building a house without architectural designs. Why should software development be any different?
I'm not a man to idly tell people "I told you so", but I'm sorely tempted when the team next door spend several man-days involving the whole team in a discussion about "where this interface should go" in a 100+ project solution. If your solution has 100+ projects and you haven't already visualised your packages and dependencies, you are TRWTF. Never mind the fact that you should have started by visualising your solution structure before you even touched Visual Studio. You'd be able to do away with all "refactoring sprints".
I've been around a fair while and no matter where I go, be it a Fortune 500 company or a brand new startup in someone's spare room: in 13 years I've never seen a development process that devotes adequate time, knowledge and resources to software architecture and design. everywhere you go people cut corners or are so hubris-ridden that they think they're above any WTF and the worst thing is, nobody learns.
Because software is soft - it is much harder to alter a building after its been constructed.
Physically harder, indeed. But then again: Moving things around and adding/deleting features in software is much easier when the data access does not do any UI operations (and the UI does not access the database without the dataaccess), eh?
That's where the actual logic get built. That's where the methods and everything you have learned get applied. (Commenting code, naming conventions etc.) That's the part from where KT is needed; and if it built perfectly then project will be live always no matter how many people will work on it.
I always love to be core part of actual coding and building logic.