[Matty919]

I am soon to be attending a few different interviews relating to a development role and wanted to ask some questions about software development. I am in my second year at university and have taken a few modules relating to software development but struggling to see how it all fits together.

When I create software I am often tasked to follow the whole development life cycle in a brief way. I am usually given a requirement specification - what the software has to do, design it using UML diagrams and/or pseudo-code then I write the code. I am then tasked with providing test cases so in a way I am following the standard lifecycle: Analysis -> Design -> Implementation -> Testing -> Maintenance.

My design though is generally just pseudo-code on paper and other scribbles. I find if I create UML diagrams (usually class diagrams) or type up my pseudo code then I just end up having to change it. The reason I have to change it is that when I write my code I realise some things don't work as intended, some things could be done better in other ways or my original design in some way was wrong. For example if I create class diagrams and then I realise I need extra or less methods.

My question: does this happen in industry? I assume the design can't be perfect and changes tend to be made? Is the original design updated? How often is the design updated? Is it done in phases? i.e. implement the first version using original plan then design possible changes and implement those?

[tlhIn`toq]

Ahahahaha... LOL... That's so textbook.

In my workplace its just like that - only without any of it.

Boss, Wednesday night at 1700hrs: I need you to build an application that can run a WidgetBrand camera... take into account everything our customer needs. I need a prototype by Friday and the finished version the week after. Have it look nice, be so easy to use that a caveman can do it: It should be intuitive and not require any kind of documentation or help files. Its just you, no team, and the QC guy is out doing an installation this week so be sure to do all the QC yourself so it can just roll out to the customer working right the first time.

And by "the week after" he means Monday.

So my diagrams are more like fast blocks drawn on a whiteboard.

Welcome to the real world instead of university.

[jon.kiparsky]

Half-assing it is the norm in some shops, it's true. But don't let that stop you from understanding and using best practices when you can - on your own projects, and in your school work. The more you do design right, the faster and better you'll be at it, and the more design you'll be able to cram into tlhIn`toq's compressed timeframe.

But that's more like the real world, which wasn't your question. For an interview, you want to be able to show that you understand good design practice (this is your question, I think) and also that you understand that good design can't be allowed to interfere with eventually getting a product out the door. Think about making the calendar central to your process from the beginning. When you get a deadline, you want to be able to make a good guess as to how much design will fit - whether it's fifteen minutes at the whiteboard or a week with the client - and how much time will actually improve the actual outcome.

As always, in an interview you want to understand what the guy on the other side of the desk feels is important, and to convince them that you can deliver that. If they want monobuttocked code-that-works by next Tuesday, and you can do that, sell them that. If they want anal-retentive move-that-pixel-to-the-left Apple polishing, and you can provide that, sell them that. Most people want something in the middle, so you need to figure out where in the middle that is, and put yourself there.