Tuesday, October 24, 2017

The Mythical Man Month - Chapter 4 Aristocracy, Democracy, and System Design


Cathedral
  • Conceptual integrity is the most important thing to consider in software system design
    • It's a lot easier to debug and maintain when formatting, language, structure is consistent throughout the system
  • Systems with conceptual integrity have on set of design ideas and any other design ideas conflicting with it must be excluded
  • How is conceptual integrity achieved?
    • Ease of use
      • Ease of use dictates unity. Ease of use can't exist if the design consist of separate ideas that make the system both less straightforward and simple
  • Unity design comes from one or small subset of architects
    • Due to schedule pressure, software projects use a lot of developers to design and develop the system
    • Two solutions to schedule constraint
      • Separate design and build resources
        • Architect - develops designs in advance of developers
          • Developing a description to what is suppose to happen
        • Developer - Takes the designs
          • How to implement those designs
      • Using the surgical team structure where 1 person is responsible for the flow and the outcome of the project
  • What do developers do while waiting for architects?
    • Issues
      • Sometimes developers can't develop what architects design because it's overly complex (Will get into that more in the later chapters)
      • Developers don't have a say in creativity - creativity for developers comes from how to implement the designs within the boundaries and constraints given
      • Developers are sitting and waiting for architects - Technically architects should have a bigger lead time then developers
    • The architecture, implementation the realization can be worked on in parallel


My Thoughts: I heavily believe in Brook's approach that there should be an architect and a developer. Although I haven't seen this done in most companies because they feel like it be a waste of time, I strongly believe that you get the work done a lot quicker.

Friday, October 20, 2017

The Mythical Man Month - Chapter 3 The Surgical Team

The Surgical Team

  • Young program managers prefer small, sharp team of first-class people rather than hundreds of programmers who are medicore
  • The problem is there is a wide productivity variation between good programmers vs poor ones
    • Between best and worst performances averaged about 10:1 on productivity measurement 
    • 5:1 on programming speed and space measurement
    • In short: $20,000/year programmers may be 10 times as productive as a $10,000/year one
    • There is no correlation between experience and performance
  • Large software teams are broken into "surgical teams"
    • Each team is headed by a chief programmer - the surgeon
      • Chief programmer does most of the programming
  • The surgical team
    • The surgeon
      • The chief programmer
        • Defines the functional and performance specifications, designs the program, codes it, tests it and writes its documentation
    • The copilot
      • Alter ego of the surgeon
        • Ability to do any part of the job
        • Less experienced
        • Main function is to share in the design as a thinker, discussant, and evaluator
    • The administrator
      • Handles money, people, space and the machine
    • The editor
      • Takes the draft of the documentation and criticizes it, reworks it
    • Two secretaries
      • Handle project correspondence and non-product files
    • Program clerck
      • Responsible for maintaining all the technical records of the team
    • Toolsmith
      • File-editing, text-editing and interactive debugging services
    • Tester
      • Writes test cases and then testes the whole thing
    • Language lawyer
      • Find neat and efficient way to use the language to do difficult, obscure, or tricky things



My thoughts:

When reading this chapter, it seems very odd because this is not a structure most software teams are work. Typically you have lead developers, senior developers, junior developers and QA (automated and manual).

One of the biggest problems in software teams is communication overhead; more developers, more overhead. Even with all these new and upcoming tools like Jira, Slack, Google docs and more there is still a lot of communication overhead. Miss one meeting and sometimes it feels like you're already out of the loop. Also making sure you include the right people in the communication channel is important as well, but meetings can be expensive.

I did some research to understand the proposed software team structure and it looks like this structure was used back in 1975. Although I wasn't alive at that time, reading other people's experience it looks like language lawyers were necessary because compilers back then wasn't as good as it is today. This book was written in 1975 and software has changed a lot since then, but there is a lot of important information here to learn.

One thing that has changed drastically is, one or two people really understanding system. In my experience it's critical for the entire group to understand the entire system. The reason why I believe that is if one of the two people quit the group, you just lost someone vital. Now you're only left with 1 person really understanding the system.

I think too many people these days pride on being a critical person to a team. They want to make sure the ship sinks without them in it. I.e. if I quit this company today, the group would be crippled. But... I feel that's the wrong way to go about it. Sure, you may feel more important to the team, but I really think your skills come into play when you can teach a junior developer how the system works. A good leader will be able to explain the system to anyone on his team. If you want to actually stand out, you will by being a better performer. You know how architect the system. You understand what type of tools you can use to help you in developer. You use the right approach for debugging. You make the right trade-offs at the right time. Those attributes is what differentiates software developers in my point of view.

Tuesday, October 17, 2017

The Mythical Man Month - Chapter 2 The Mythical Man-Month


Antonine's New Orleans Menu

  • A lot of software projects have missed deadlines - What is the cause?
    • Estimation techniques are poor
    • Estimating techniques confuse effort with progress
      • Men and months are not interchangeable
    • Uncertain of our estimates
    • Progress is poorly monitored
  • When schedule slips the natural reaction is to add more bodies, but often makes matters worse
  • A lot of programmers are optimists
  • A software project contains many tasks, second chained end to end and the probability that each task will go well is very small
  • The man-month as a unit for measuring the size of a job is a dangerous and deceptive myth (it implies that men and months are interchangeable)
    • Men and months are interchangeable commodities only when a task can be partitioned among many workers with no communication among them
  • The bearing of a child takes 9 months, no matter how many women are assigned
    • Many software tasks have this characteristic because of the sequential nature of debugging
  • If schedule time is fixed
    • Like a chef cooking an omelet, he can turn up the heat but that rarely turns out right
  • In tasks that can be partitioned but which require communication among the subtasks, the effort of communication must be added to the amount of work to be done
  • Communication is made up of two parts; training and intercommunication
    • Each worker must be trained in the goals, overall strategy, plan of work, technology
    • If each part of the task must be separately coordinated with each other part the effort increases as n(n-1)/2
  • The part that affects schedule the most is debugging and system testing
  • How to give better estimates
    • Reschedule
    • Trim the tasks


My thoughts:

There has been only one case where I ever worked in a software company where we released "on-time". I write the word on-time with quotes because I want to emphasize that it wasn't with all the features that we wanted projected. We were working towards a fixed schedule and the managers said we are releasing in 3 months whether we like it our not. (Also mind you, the software product was already in the field, so it was more of a regular software update). In the past, the company had updated that software every 3 months and they weren't going to change that now so it didn't matter if you didn't get your feature in or not. (Only mattered at your performance review and you better have a good answer)

So what method do I use to do software estimation. I don't think my technique is fool proof and I've been improving my method over the years. The techniques I use to estimate my schedule is by taking data. I don't let optimism or emotions get in the way of butchering my schedule. It only makes it worse. 

So what I mean by that is, in a current project I am working on. I take all the known features initially and jot them all down onto an excel sheet. Next to that column, I write a description on what I think the requirements are for that feature. On the column over that, I write an estimate on how long that feature would take. (You should do this for yourself because each person will give a different estimate so at least if you're off in your estimate since you're the only variable, you'll be off for everything to a similar degree). Next to the column I write how long it actually took. After that column I have a section called comments/thoughts and leave the whole column blank after that. It's a very tedious process, but I truly believe it's worth the effort. Once I am done filling the entire sheet out, I write a date on when I finished the entire sheet. 

Now whenever I complete a task, I go back to my sheet and write how long it actually took next to it. If I was wrong in my estimate, I write why/feedback. Maybe I was blocked by designer, my requirements changed or I just had too many meetings that day. If you're working in a team and you're managing it, you can write why you think it took them so long, talk to them about it.

An example of what it looks like

Every 2 weeks, I review the sheet to make sure everything is up to date and if and only if something has changed, I create a new sheet and copy the old sheet over. I add the new changes onto the new sheet only! The reason why I don't reuse the old sheet is because I want to have a reference point on what I thought originally. This is very important. I know file servers like dropbox you can retrieve old history, but I keep it old school. I do this until a certain milestone like Alpha, Beta, Release and etc.

After each milestone, I review my old notes and see how off I was in my estimates. (The first time you'll be off, but as time progresses hopefully you'll be better in your estimates) What was my estimate originally and what was it in reality. That gives me insight onto how off my schedule was and for the next milestone I can plan better because now I have actual data. 

I strongly believe that's the best method in my experience. It's tedious, but I think it's worth the effort. And you'll find that each company is unique. No I would even go far as each team is unique since each team has a different personality. You'll soon learn that that your initial estimates were off my a factor of 2 or even 5 because that certain company tends to have a lot of overhead like meetings, events, people who take vacations and more and next time you can put that into consideration. 

I understand you can't do this for every project and you'll have to make the right tradeoffs to see if it's worth the effort.

Friday, October 13, 2017

The Mythical Man Month - Chapter 1 Tar Pit



Tar Pit

  • Large scale programming applications over the past decade has become extremely complicated
    • Very small amount of programming applications meeting goals, schedules and budge
  • People hear about famous garage programmers who can create amazing applications far better than corporate teams at large scale companies

    • Then why haven't all companies replaced programming teams by garage duos?

  • Why do people enjoy programming?
    • Five reasons: 
      • Sheer joy of making things
      • Making things that are useful
      • Fascination of complex puzzle-like objects
      • Always learning new things
      • Working in a tractable medium
  • What makes programming not fun?
    • Programmers are expected to be perfect because a program will do exactly what you tell it to do (Very few human activity demand perfection) - Difficult part of learning to program
    • Other people set one's objectives, resources and information (Rarely programmers control the circumstances of his work, or even its goal)
    • Dependencies on other people's programs that are often poorly designed, poorly implemented, incomplete, lacks testing and poorly documented
    • Finding bugs - hours of tedious debugging. The last difficult bugs taking more time to find than the first
    • Product has been worked on so long that it appears to be obsolete upon/before completion. (Competitors are already looking for new/better ideas)


My thoughts:

It's very true that programming has grown more complex in the past decade. People's expectation on what is a good software product has risen dramatically. Take Pac-Man for example, three core people worked on that project (1 designer, 1 programmer and 1 focused on developing music) and although we don't consider the graphics anything outstanding in today's standard, back then it was perfectly acceptable, which it generated more than $1 billion dollars in revenue. Last I heard, it took more than 1,000 people to develop Grand Theft Auto V. Also it took the team more than 5 years for the game to be released.

But... I've met many people who tried to manage software teams that haven't programmed in large teams/worked on large-systems don't understand how software works for themselves. This often leads to a lot of trouble because their idea of how software applications are developed is skewed. You'll often see them complain why the team is always over budget, under-delivering and way over schedule because they simply don't understand software. Most companies want to create a programming system product, but want it to cost as much as a program.

Why do I enjoy programming? I personally love making products that I can use. Now If I skip a day of writing a single line of code, something feels off.

What makes programming not fun? I enjoy a lot of aspects of programming, even issues that the book mentioned like dependencies and finding bugs. I actually really enjoy finding bugs and working with projects that have a lot of outside dependencies, because those are challenges to me. One aspect I really dislike is someone who is trying to manage software that has no clue about how programming system products are developed, but pretend like they do. I don't mind if this is your first time managing a software team, as long as you're open minded, willing to learn and putting in the time and effort.