Modern software engineering students dream off code dtslob (1)

 

1

As you see, I 've marked this post number 1. let's leave the last post on "Dreaming in code" number 0 this time, I will focus on the issue of people, partly based on chapter 0 and 1 in that book.

Why focus on people? Think about our group, think about your group. What is the purpose of this course and projects we have done? To practice and improve our skills in C #? Obviusly not. From iproject, to pProject, And the tproject we are currently doing, we are experiencing the process of dealing with more and more people, and then, more and more trouble.

2

It's "difficult to produce computer software on time and under budget ". (Quotation around sentences, in texts below and following posts, means copying the original sentence from "Dreaming in code ".) in essence, is it really the time or money or experience problem?

Students in our class are all considered as programming masters, having written so far projects for professional courses, some even having oi experiences. But what happens in our group and your group? Predictional examples:
1. A classmate complains to me that one member of his Group violently expressed the impossibility for him to write any code.
2. A classmate in some group always promises to write code the next day, but his work actually starts a week later, because he always has unexpected social affairs.
3. in our group, Wu Yue modified a configuration item of the project on the server, and when Wang Jun checked out the next day, without an indication of previous change, cocould not even compile successfully.
4. A classmate in some group told his pm that he wocould post the first article about "Dreaming in code" on this Wednesday, because he planned to read the book that day. but he found on Wednesday evening that he didn't have enough time to read, and moreover, he had already had plans for Thursday, so he eventually started reading on Thursday evening, and he is writing this post right now on Friday night.

It seems that the complexity of software development described in "Dreaming in code" can be applied to cases everywhere. every company tends to hire people with best technical skills, tends to avoid work delay and short of money, but the dilemma appears again and again. so, it's never a technical problem. it's a matter of people, a matter of social behavior. actually, we have met plenty of issues R Elated to people in this course, like the number game. let's imagine such a situation: we, everyone in our class, go to hunt jobs in coding market. which ones can end up as a successful developer in high positions? I think this is a serious question for us to think about.

The following paragraphs address several aspects of the people issue, summarize some interesting viewpoints and sentences in "Dreaming in code", and try to add some comments if applicable.

(To be continued. I will post the next article on Sunday evening. Perhaps this means I am going to post it on Monday morning .)

3

People form groups. every group has its own interests. just like the process of revolution in society, which is always dreadful as a result of interest redistribution among groups, software cannot meet everyone's needs, and is reluctant to go forward. when the number of programmers and users both get larger and larger, this phenomenon is more likely to pervade. we can post a rule at Will on the wall at home, but a national law needs consensus among the most prestigous heads in the country. let alone all different types of user need, the thinking of programmers and users just kannot kommunicate. this idea is perfectly expressed in the book: programmers count from zero, while users count from one, and this gap simply allows bugs to flow in and out.

People need communication. That is why software development is different from other engineering tasks like building a house. How to schedule multiple "workers" so as to see actual advancement? Complexity arises as tasks assigned to different members have different interrelationships. some are serial, others parallel. when serial, "Your estimates are based on someone else's estimates", so time to finish is hard to guess. like a pregnant woman, how can you guess the time she will get pregnant again when the existing baby has not been born? How can you rely on other people's estimates? In what criterion? Based on his rich experience in building large-scale systems? Based on the estimates of an IOI winner? "Software developers are typically optimists who assume that each bug can be fixed quickly and that the number of bugs will diminish ". it shoshould be emphasized again, that this is a people issue, not a technical problem! When situation is worse that communication is unlikely, people joining afterwards are the most painful ones. for example, a typical intern in msra stays 3 or 6 months. when new interns come later, they have to read his code, lonely, and... Lonely.

How to get people into a group in a most efficient way? Distributed or centered? This is again an essential question, concerning the Battle of free packages and other cial software. in my opinion, the spirit of Internet is to share, not to hide. according to Raymond, "open source is most economical mically efficient", but why has Microsoft become a big shot? Perhaps Hoby and fun is the most loose structure of organization, lacking motivation to make quick decisions. however, getting started quickly means immature decisions as well as more bugs. so, personally, there is a point I cannot explain. the book (within chapter 0 and 1) states a lot about the superiority of distributed collaboration in GNU world with the help of Internet, but why Microsoft wi NS most of the people? (I know there are a lot of answers like "more stable and easy to use", but is there anything related to the distributed and centered way ?) And further, which one will last and finally win?

 

4

Personally, I don't like dealing with people. and I always have the feeling that I prefer not to enter the field simply filled with codes, even when I 've not actually go deep into this field yet. now it seems that I have found a reason for this.

Time of debugging the code is much more than that of writing it. when you debug codes, you debug with people actually. this shoshould be seriously considered when it comes to the demo-whether to spend a good part of life debugging.

December 08 dreaming in code blog post 2we are young. We have our dreams. People who have dreams never look back.

"It turned out that what he (Kapor) cherished was not the specific things agenda cocould do, but the program's spirit of dynamic flexibility ."

Recall the projects under "National College Students' Innovative Experimental program" which almost everyone in our class participant ipated in. whatever the initial purposes of each group were, academic or financial, we have a promising prospect at the beginning, right? During those days in Dec. 2006, when we were applying to that program and writing the Plan documents, we pictured a dream in heart more or less. however, there was one voice coming from a classmate who did not join, and which I cared not a bit: "Don't you think it's a dangerous pitfall?"

All these projects finally wound up as a crap. one important reason rooted in its own taneous participant ipants, lacking supervision due to the traditional working manner of your department and government. but in my group, you cocould find something like the descriptions in "Dreaming in code", Chapter 2. dreaming itself often does not fit into reality, and when unrealistic expectations were identified red by the naive dream, the target turned more biased from the initial schedule and the reality.

Our project was concerned about Melody recognition. it originated from my high school dream: Building a website which enabled music search by humming. in details, I wocould like to extract the melody from a wave file, index it in some way, and when someone was querying by humming a melody, his or her voice wocould also be recorded, transformed to labels of note, and searched in the database. perfect as a dream, it required much more than nowaday technologies cocould offer. after reading some papers, we realized that what we coshould do within the scheduled finishing time was a simple demo of Single-note melody recognition and comparison. so the project ended up with a system no one wocould ever use. again, it was a little aligned with the usual process of software development described in the book, "From promise to usability ".

In our current group dtslob, perhaps this problem can be avoided, because our project aims at usability from the very beginning: to handle the trouble of using IPE to display formulas, to implement drag-and-drop operations for Windows users. apart from these dream-like sentences, we have detailed steps in achieving this, and have seen good improvements so far. if you think it seems to be the same expressions with every group of software development, I cocould only say, We can see at last, and distinguish if it is again a dream.

Let's share a sentence in the end of this post, which is my favorite in Chapter 2:

In science, the whole system builds on people looking at other people's results and building on top of them. in witchcraft, somebody had a small secret and guarded it-but never allowed others to really understand it and build on it. traditional software is like witchcraft. in history, witchcraft just died out. the same will happen on software. when problems get serious enough, you can't have one person or one company guarding their secrets. you have to have everybody share in knowledge. -Linus Torvalds