OSDev.org

Hi guys,
Plz do read this essay and give me your feedback...

http://users.actcom.co.il/~choo/lupg/es ... d-uni.html

I generally agree with the author, but he didn't mention one important tool to help students learn software engineering -- work placements. I worked at two software companies during my time as a student, for a total of one year, and it was extremely valuable experience.

My first job as a developer was especially eye-opening, because the code I inherited from the previous student was terrible, and the R&D department itself was very dysfunctional. There was no process, no designs being done, just lots and lots of hacking. I spent about half my term fixing this garbage, which was miserable, but made me a die-hard fan of software engineering process. The other half of my term I got to design and implement a new component from scratch, and I produced a design doc like nobody there had ever seen.

For the component I created, I spent about six weeks learning and analyzing the problem, then another three weeks designing. When I had only three weeks left in my term, the VP of Engineering dropped by my desk and asked me if I had any code written yet. He looked worried when I said "no", and told him about my 60-page design doc. Some people have this crazy notion that if you're not coding, you're not working. I wrote the code in two weeks flat, and spent the last week unit testing it -- no problems. There were many complicating factors with threading and security (it was an ActiveX Server Component that had to call some legacy code that wasn't thread-safe -- IIS is a pain), but my design had managed to address them all.

I heard a few years later that after I left, nothing had really changed -- I guess my example didn't stick. I'm much happier with the software engineering practices where I currently work... and now, when I tell people to design first, they have to listen to me because I outrank them.

Colonel Kernel wrote:I heard a few years later that after I left, nothing had really changed -- I guess my example didn't stick. I'm much happier with the software engineering practices where I currently work... and now, when I tell people to design first, they have to listen to me because I outrank them.

Outranking people is a really bad way of making people listen. Sadly, that is exactly why my current work place is without designs, without a clue what they're doing, an accelerating deadline (not even just slipping - it's getting further as we speak) and completely against most things I really appreciate. I keep telling them to at least consider reusable components, to which I'm grudgingly getting the architect to agree.

Candy wrote:Outranking people is a really bad way of making people listen.

Agreed, but it is available as a last resort. Fortunately, at my current workplace, people are generally interested in learning and becoming better developers, so they are more than willing to listen anyway. I got the sense at my first development job that most people there were very set in their ways and wouldn't try anything new without being forced to.

I guess you might say that the key to good software engineering is first and foremost a good recruiting process.

I think the "Beer Bribe" method of coercion is very effective.. much more so actually

Brynet-Inc wrote:I think the "Beer Bribe" method of coercion is very effective.. much more so actually

I can't seem to explain much to people after bribing them with beer. It's like they're drunk or so.

Clnl. Kernel wrote

I guess you might say that the key to good software engineering is first and foremost a good recruiting process.

1. Good recruiting process (get people who can program)
2. Good management (keep those people and kick out those that are slacking)
3. Good HRM (keep the people who are here educated and top of the line)
4. Good support (if you don't give me tools to work with, I can't work - if your tools slow me down, I'll not do much)

After that, the important parts are covered. My current company (company where I'm placed) misses out on at least 3 of these, possibly 4.

Candy wrote:After that, the important parts are covered. My current company (company where I'm placed) misses out on at least 3 of these, possibly 4.

Buying the latest VS every year, I guess?

Back to the universities (actually, I've tried just one enough to say something about it: mine). Mine provides four courses directly related to software programming: Software Architecture, Software Engineering, Modelling and System Development, and The Project, the last two being required for all computer science students. I've completed three of them, and I'll be doing the fourth one (software engineering) the coming season.
Modelling and system development is the typical failing course as the essay describes. Bad teacher (in the sense of being worth an fail grade in didactical qualities - I spent some colleges asleep because of it), and having to believe him on his word. And then we had only three colleges and one 2-hour assignment involving programming patterns. With some wisdom you could apply the theory to other assignments, but none of them were large-scale enough that it mattered.
Then there was Software Architecture: more sleeping hours, but at least it came with a good book full of experiences and live examples of why to use certain designs and why not use others.
A year later I decided on taking on the Project. We had to write a plug-in testing environment for computer vision algorithms. The main goal was obviously to allow many additions in the (far) future. Instinctively we grabbed to a set of patterns, but soon it became obvious that doing it otherwise would have had horrible consequences.

That said, you learn from mistakes more than successes: The two rewrites of my kernel taught me that a design must be awfully complete to oversee what needs to be done. (I never wrote down my kernel design, so there are probably some loopholes left over). Another project learnt me how annoying customers could be - although this is the most crappy project that is currently in use it stands as a good example to think before writing code.

IMO universities are too limited to teach proper software engineering in the 3 years they are supposed to pump students to Bachelor degree. Getting encumbred by your own errors is a good drive to improve. Having students run a project each year would take lots of time away from other courses which are obviously also required for a good education, but I do think it would help if most programming courses would involve a two-stage assignment: for the first assignment, write a program; for the second one you have to improve and expand on it. Without using patterns, it gets annoying very quickly, which is in turn a reason to use those patterns.

In essence, I agree with Colonel Kernel and Candy in that proper software engineering requires live experience, but proper educational institutes can arrange for a good part of that experience in-house.

€.02

I am guessing:

It is caused by the desire for work to produce profit. You subtract design time from profit. The design time is a cost. That is why you get a certain expected quality of software from the industry.

If the management feels that you are over designing then they feel like they are losing money. The component might be half way working, but if it makes more money than the rock solid stability of another component then guess which one the company likes more?

Kevin, you hit it right on the head: People who have only a passing knowledge and experience of creating software (the managers) "feel" that you (the software engineers) are wasting time because they don't understand that a week saved today is a month spent in maintenance agony later.

And because we (the software engineers) are much better at our job than management would ever give us credit for, we somehow make it work even if they did cut our guesstimate in half, fired half our co-workers, and didn't back us up when we complained about the half-assed requirement specs given to us by the customer. Still, we make it work, somehow.

Which only results in management feeling proven right that our guesstimate was wildly off, and our complaints misjudged, so they do it again the next time.

Solar wrote:Kevin, you hit it right on the head: People who have only a passing knowledge and experience of creating software (the managers) "feel" that you (the software engineers) are wasting time because they don't understand that a week saved today is a month spent in maintenance agony later.

That depends on the scale of your project. If I had my say about 2.5 years ago they'd have saved a few months by now, probably more.

And because we (the software engineers) are much better at our job than management would ever give us credit for, we somehow make it work even if they did cut our guesstimate in half, fired half our co-workers, and didn't back us up when we complained about the half-assed requirement specs given to us by the customer. Still, we make it work, somehow.

To be quite honest, my co-workers are leaving of their own accord, the guesstimates weren't cut in half but we don't really get time to guesstimate, nor is there a base layer of code to build on. We also didn't get requirements or specs, and the one time I did get them they were both worthless and they changed so invasively that I might as well not have had them.

Which only results in management feeling proven right that our guesstimate was wildly off, and our complaints misjudged, so they do it again the next time.

Not to mention the thought that they must be doing everything right even though there is no spec, the product is hopelessly unstable and over date, and horribly unmaintainable.

Nice to see that after all that time we can still agree violently on certain topics.

This article was a real eye - opener for me ... mainly because i come
from a background where showing the "output" quickly is more
important than everything else .... I am just a student ... The more
quicky you show the output ...better grades you get ... No one
will ever check our code ... They just watch the output ... This
is a faulty practice which exists in our entire state .... Also we
have no implementation projects as a part of your caricullum....

But during the university lab exams you may be asked to write
a major part of compiler or a compleate assembler in just under 2-3 hrs
..Which obviously is a bit hard ...and .. needs some luck as well....
(err ... sometimes we are forced to make some manipulations to
make the output "seem" correct)... Although i get the "output"
all the time ... The programs i wrote are far from optimal.....

Thanks everyone from osdev for your comments

SandeepMathew wrote:The more
quicky you show the output ...better grades you get ...

Once you get into apps with GUI, a hint from the field:

Never fall into the trap of "mocking up" a GUI in VisualStudio for a presentation. It's quick, it's easy, it looks great on the beamer, but you just shot yourself in the foot. Customer cannot distinguish between mock-up and finished product, and will assume you are much further down the road than you actually are. He'll scream bloody murder when, after seeing the "finished" GUI in a presentation, the implementation takes another couple of months.

Worse still, he'll scream bloody murder if you make changes to the layout after the presentation.

Only show those parts "in GUI" that are actually finished. Use hand scetches for the rest, to show it isn't finished.