[[ blog 이사 과정에서 정확한 posting날짜가 분실됨. 년도와 분기 정도는 맞지 않을까? ]]

PhaseEffort and SizeSchedule
OptimisiticPessimisitcOptimisiticPessimisitc
Initial product concept0.25 4.0 0.60 1.60
Approved product concept0.50 2.0 0.80 1.25
Requirements specification0.67 1.5 0.85 1.15
Product design specification0.80 1.25 0.90 1.10
Detailed design specification0.90 1.10 0.95 1.05

< Source : Adapted from "Cost Models for Future Software Life Cycle Processes : COCOMO 2.0" (Boehm et al. 1995) >

[[ blog 이사 과정에서 정확한 posting날짜가 분실됨. 년도와 분기 정도는 맞지 않을까? ]]

 Systems ProductsBusiness ProductsShrink-Wrap Products
System Size
(lines of code)
Schedule
(month)
Effort
(man-month)
Schedule
(month)
Effort
(man-month)
Schedule
(month)
Effort
(man-month)
10,0008 24 4.9 5 5.9 8
30,00013 97 8 20 9 32
50,00016 190 10 40 11 67
100,00022 450 13 93 15 160
200,00029 1,300 17 210 20 360
300,00034 1,650 20 345 24 590
500,00042 3,100 25 640 29 1,100

< Sources : Derived from data in
Software Engineering Economics (Boehm 1981),
"An Empirical Validation of Software Cost Estimation Models" (Kemerer 1987),
Applied Software Measurement (Jones 1991),
Measures for Excellence (Putnam and Myers 1992),
Assessment and Control of Software Risks (Jones 1994)>

[[ blog 이사 과정에서 정확한 posting날짜가 분실됨. 년도와 분기 정도는 맞지 않을까? ]]
 

Comparison of Motivators for Programmer Analysts vs. Managers and the General Population.

Programmer AnalystsManagers of ProgrammersGerneral Population
1. Achievement 1. Responsibility 1. Achievement
2. Possibility for growth 2. Achievement 2. Recognition
3. Work itself 3. Work itself 3. Work itself
4. Personal life 4. Recognition 4. Responsibility
5. Technical-supervision opportunity 5. Possibility for growth 5. Advancement
6. Advancement 6. Interpersonal relations, subordinate 6. Salary
7. Interpersonal relations, peers 7. Interpersonal relations, peers 7. Possibility for growth
8. Recognition 8. Advancement 8. Interpersonal relations, subordinate
9. Salary 9. Salary 9. Status
10. Responsibility 10. Interpersonal relations, superior 10. Interpersonal relations, superior
11. Interpersonal relations, superior 11. Company policies and administration 11. Interpersonal relations, peers.
12. Job security 12. Job security 12. Technical-supervision opportunity
13. Interpersonal relations, subordinate 13. Technical-supervision opportunity 13. Company policies and administration
14. Company policies and administration 14. Status 14. Working conditions
15. Working conditions 15. Personal life 15. Personal life
16. Status 16. Working conditions 16. Job security

< Sources : Adapted from Software Engineering Economics (Boehm 1981) and "Who Is the DP Professional?" (Fitz-enz 1978).>

[[ blog 이사 과정에서 정확한 posting날짜가 분실됨. 년도와 분기 정도는 맞지 않을까? ]]

From rapid development (Steve McConnell)

* PEOPLE
- Undermined motivation.
- Weak personnel : "Should be suitable person (Not available person!)"
- Uncontrolled problem employees.
- Heroics : Always shouting "Can do" and don't report risk till last stage of project.
- Adding people to a late project.
- Noisy, crowded offices.
- Friction between developers and customers.
- Unrealistic expectations.
- Lack of effective project sponsorship.
- Lack of stakeholder buy-in.
- Lack of user input.
- Politics placed over substance.
- Wishful thinking.

* PROCESS
- Overly optimistic schedules.
- Insufficient risk management.
- Contractor failure.
- Insufficient planning.
- Abandonment of planning under pressure.
- Wasted time during the fuzzy front end.
- Shortchanged upstream activities.
- Inadequate design.
- Shortchanged quality assurance.
- Insufficient management controls.
- Premature or overly frequent convergence.
- Omitting necessary tasks from estimates.
- Planning to catch up later.
- Code-like-hell programming.

* PRODUCT
- Requirements gold-plating.
- Feature creep.
- Developer gold-plating.
- Push-me, pull-me negotiation.
- Research-oriented development.

* TECHNOLOGY
- Silver-bullet syndrome.
- Overestimated savings from new tools and methods.
- Switching tools in the middle of a project.
- Lack of automated source-code control.

[[ blog 이사 과정에서 정확한 posting날짜가 분실됨. 년도와 분기 정도는 맞지 않을까? ]]

Ideally, duplicated code leads to maintenance nightmare. So, Not-allowing-duplicated-code always seems to be better. But, in this article, I want to say that in some cases, code-duplication needs to be allowed.

In practice, lots of people who has different ability work together in one source code branch. In this case, if code duplication is not allowed, all developer should search all sources to find the reusable module. Let's image that there are thousands modules. Finding appropriate module is not easy. And lots of people try to customize(modify) the module for easy-reuse. If all engineers are enough good at programming and enough time to consider code quality then we don't need to worry about "customization". But, it cannot be in some cases - especially, product development. Skill level of engineers are always various and they are always pushed by project schedule. So, the shared module tends to become worse and worse in terms of its quality. (It's normal in large-size-project).

Here is merits of allowing code duplication.(There are lots of well-known-disadvantage of allowing code duplication. So, let's talk about only "Merits".)
  * There is no dependency among people. So, it's very easy to work in parallel.
  * Merging is easy, because of no-dependency and no-conflicts.
  * Bug from mistake affects only limited area. So, detecting issued part is easy.

So, practically, we need to consider what should be reused(shared) and what shouldn't.

Here is my opinion about this.
Codes that should not be duplicated.
  - codes for interface with external modules.(In App. point of view, OS, filesystem and so on can be external modules)
  - codes that are used very frequently. (ex. code for getting lengh of string. - strlen)
  - stable codes.
  - ... (anything else???)

Codes that can be duplicated.
  - parts that should be done in parallel with tight schedule and enough human resources.
  - codes that are customized very often.
  - ... (anything else???)

Hmm... I need further study...

[[ blog 이사 과정에서 정확한 posting날짜가 분실됨. 년도와 분기 정도는 맞지 않을까? ]]

큰 팀이 project를 할 경우, 팀내 개발자 각각의 local환경이 서로 틀려서, 문제가 생길때가 많다. ("나는 build가 잘 되는데, 너는 왜 안되느냐?" 등). 그래서 보통의 경우, 같은 project를 하는 사람들끼리는 개발환경을 통일하는 경우가 많고, 이런 개발환경에 대한 script file또한 형상관리의 대상이 되는 경우가 일반적이다. 환경을 통일하기 위해서는 각 개인의 Local환경을 공통 환경으로 Mapping시켜 주는 일이 필요한데, 보통의 경우, 환경 변수, Virtual Drive 등이 쓰인다.

예를 들면,
- 개발 root directory는 "P:\project"로 한다. => Virtual drive를 이용.
- project build directory는 %MY_PRJ%\%PRODUCT_NAME%으로 한다. 등등

그런데, 개발환경이란, 비단, file path, 개발 tool의 path, 환경 변수의 차이 등을 의미하는 것 만이 아니다. source code editor도 주요한 개발환경이라고 할 수 있다.

어느 한 'A'라는 editor에서 개발한 사람이 줄을 잘 맞추어서 정돈된 코드를 만들었다고 하자, 이 코드가 'B'라는 editor에서는, 'tab size의 차이', 'font의 width'차이 등으로 인하여 무질서 하게 보이는 경우가 허다하다. 즉, 'A'라는 editor를 기준으로한 code beautify는 'B'라는 editor에서는 무의미할 수도 있다는 말이다.
그런데 문제는 다른 개발 환경과는 달리, code editor는 개발자들에게 '통일'을 강조하기 어려운 면이 있다는 것이다. 왜냐하면, 개발자들이 다년간 사용한 editor를 바꾸게 된다면, 한동안 새로운 editor에 익숙해 지기까지 꽤나 긴 시간동안 생산성이 크게 떨어질 뿐만 아니라, 개발자 개개인의 커다란 반발을 살 가능성도 농후하기 때문이다.

따라서 차선책으로, editor 환경을 통일시키게 된다. 개개인 개발할 때는 임의의 editor환경을 사용해도 좋지만, code branch에 'submit'한다던가, 'check in'할 경우는 반드시 통일된 editor환경에서 beautify된 코드를 사용하도록 해야 한다. (사실 매번 submit혹은 check in할때마다 이런 작업을 해야 한다면, 개발자들은 차라리, editor환경을 여기에 맞추게 된다. editor환경을 바꾸는 일은 editor자체를 바꾸는 것보다는 수월하며, 또 반발 또한 작다. 왜냐하면, 이것은 editor 자체를 바꾸라는 것 보다는 당위성이 충분하기 때문이다.)
code editor 환경의 예를 들면 다음과 같은 것이 있다. (너무 복잡한 규정은 잘 지켜지지도 않고, 반발만 살 수 있음을 명심해야 한다.)

- tab은 space replacement로 하되 size 4로 한다.
- 줄바꿈은 Unix style(LF)를 따른다.
- ... etc..

+ Recent posts