Friday, December 31, 2010

Where are the algorithms?

In the highschool programming was interesting. We learned linked lists, backtracking, and other algorithms. I made little programs with rotating things in Turbo Pascal (i.e. planets moving on a leaned ellipse path), tried to imitate GUIs (start menu, windows), made a snake game.

At the university we learned other algorithms and design patterns. It was also interesting.

But all the above had too little to do with what a programming job is about. Programming for a living mostly means arranging list views in tabs and showing data gotten from some server. It's hard because of lacking a real spec (not just screenshots, but actually knowing what the program should do in the background), not being able to test it (i.e. no access to the server from which the data is gotten), no up-front design (not defining the api between the layers; not assigning features clearly to developers), a technology switch every year, complicated UIs; not because of the algorithms involved. All this is the same in every program. And after doing this, you start to ask what the heck are you doing. Where's the fun in coloring and arranging list boxes and buttons, and filling them from a database table or from a service? Why were computers invented, if they don't compute anything, just show the contents of some tables, in a zillion ways (each program in its own way)?

Thursday, December 2, 2010

How too much project management slows down projects

At first look, managing risks by splitting the project into milestones, and assigning full features for each milestone, should help projects. But, as I've seen so far, it puts all the developers to work on the same part of the program, having merge conflicts, especially if each code piece needs to wait for code review, in the meantime gathering more conflicts.

Another slowdown comes from the fact that the code for each feature needs to be understood by more developers (because both DeveloperA and DeveloperB work on Feature1 in Milestone1, and both work on Feature2 in Milestone2), and understanding code and specs takes up a good amount of time.

Perhaps the classic waterfall model is not that bad after all, and we'll see a return of it in 5-10 years.

Tuesday, May 25, 2010

The new fashion: Code Review

Is code review, no code ownership (5 people working on the same small feature), scrum, and monthly/weekly deliveries better than the traditional coding ?

Frequent deliveries rush the project at the beginning, skipping the design phase, thus the program will have a lot of almost duplicated code.

If there is no code ownership, when a new method is needed, it is just added to the existing class, because reviewing a patch that has added functionality plus refactoring is hard. And nobody wants to break already tested, existing code, close to a frequent delivery.

Maybe the waterfall model is not that bad after all. If I'm the owner of all the code of a small feature, and it has not been thoroughly tested yet, I'm a lot more willing to refactor and design the code properly. Otherwise there is a risk of stepping on each others' toes.

The errors caught on code reviews often mask a bad spec or a rushed up initial technical design. Trivial errors are often caught anyway by the author of the code or by the testers, 2 days after the code is written, and can be easily fixed. If people work on different areas of the app, I don't care that my collegue's area does not work as expected for 2 days. If it does not crash the program on startup, and does not crash my feature, I'm ok with it.

If 5 people work on the same small feature and everyone is working on each layer of the app, a lot of time is spent by each of them to learn the existing code. Doing something the first time can take 10 times longer than doing it the 5th time. So, no code ownership can waste 1 week of each of these 5 people's time just to learn the existing code, the "model" of how to add the new code. All these 5 weeks just to don't need to have 1 developer spend a week on ramping up on a collegue's code, when he eventually leaves the company. It seems a high price to me.

Code review is still useful to learn programming tricks from the collegues. But this learning review can be done more rarely.