Archive for the ‘software engineering’ Category
Dreaming in Code
I just finished reading Dreaming in code by Scott Rosenberg.
In this book, Scott tried to answer the question on why is building software is so hard. To answer the question he spent 3 years following the development of an open source PIM project called Chandler.
It was a very interesting book albeit it’s also a quite depressing one. In the end I got the impression that we cannot find an answer why software is hard, it just is. For the case study itself, Chandler was started in 2002 and now 6 years later it only managed to reach 0.7 release.
There are some really good quotes in this book, these are few of them:
On the subject of information distribution speed by the internet:
That means you couldn’t afford to perfect anything - but no need to worry because nobody else could, either.
Their work (developers) is one percent inspiration, the rest sweat-drenched detective work; their products are never finished or perfect, just varying degress of "less broken".
Brook’s Law - Adding manpower to a late software project makes it later
In the software world, most of the choices that arise boils down to one particularly heartbreaking three-way trade-off … There’s an old saying: I can make it for you fast, cheap or good. Pick any two.
… effort to produce a "perfect spec" … would prove an infinite labor; you’d never finish spec writing and start coding.
… agile development and XP are best for small teams of experienced coders.
XP can quickly decays into a means to … "Deliver Crap Quickly"
Software developers always have more to do; the definition of "done"; … is always somewhat arbitrary… "Done" is something that you must decide for yourself.
I got introduced (and re-introduced) to some people whose work I would love to read: Frederick Brooks, Mitch Kapor, Joel Sposky, Martin Fowler etc. It was very enjoyable reading experience, I literally can’t put it down, definitely recommended reading.
Rules to better team members
I stumbled across SSW’s rules to better team members and rules to better project.
I haven’t read much of the later, but I read most of the points of the first one. There are good points there, although most of them are just common sense. Having said that, common sense is not common, is it?
I would want to see whether the points preached are also practiced there, but at least having those points compiled and put up for everyone to see is a good start. I would like to see lists like this for our company and that people are actually working towards better work environment and process.
These are points of interest:
- Point 13 turning free work to billable hours. On my terms, this means do not be too lenient to our clients (ie doing lots of free work) and do not over estimate your capabilities to deliver, eg if you promised to do something in x hours of time but turned out that it actually takes x+y hours, then of course you have to work the additional y hours for free.
- Point 8, persistence when you think some things need to be done and create a list somewhere to store your thoughts on these things. I think this is an excellent point, I have done this for previous company, I created a list of things that they can improve on, but I somehow I just didn’t give the list to them when I left and I can’t remember exactly why. I probably should start my list and give it to my boss (before I leave).
- Point 38, knowledge sharing. I am a huge fan of knowledge sharing, I set up a Wiki at my old workplace (which unfortunatelly hasn’t been updated since I left) and tried to put up some of my knowledge and experience in my current workplace’s wiki and chase up the Chief Architect to put up his as well.
Some points that I think are questionable (and a bit silly):
- Point 74, always carry a thumb drive.
- Point 34, don’t listen to music at work. I actually can understand this point, but I personally think listening to music helps me a lot in tasks that require undivided attention.
- Point 52, speak correct Egnlish. What happen if you are not a native english speaker? Surely you can forgive someone having grammatical or pronounciation errors at times, as long as he can communicate well.
All in all, it is a good guide to read up and to reflect, kudos to the SSW to put it up on the net so that others can benefit.
Software Design Process
- Waterfall - structured and systematic analysis at each step before proceeding to the next
- Spiral - rapid generation of increasingly functional systems, short turn around time, quick turn around
If it were up to me, the waterfall approach seems to be more reliable to produce robust software however spiral approach seems to be more applicable for a web application.
Skill Divide
I was reading a very interesting article on Coldfusion’s Skill Divide by Brian Kotek.
He basically found that CF programmers mainly fall into two extremes those who embrace cutting edge development techniques (and software engineering practices) and those who “embed queries in their display pages”. I think his observations hold true for programmers in general. There are people who content with whatever process in place (main focus is to get jobs done period) and those who seek to improve (get jobs done in better quality with as a result of a better process).
*Side note: I found out some of a company’s (name withheld for privacy and confidential issues) past projects were laid out using HTML tables and these were sites built at least after the year 2000 when surely CSS has accepted as a web standard. I cannot judge on why this was the case, as I wasn’t there when these sites are built. But one very plausible cause is either over worked developers or developers not interested in skill improvements.
I find it hard to believe that anyone who wants to be in the IT industry should want to be in the first category. Nothing is wrong with just aiming “get jobs done period”, cause at the end of the day that what’s management wants, but I think having that sort of mentality will disadvantage the developers themselves in the long run.
So if I want to be a developer who can improve over the time, what should I do? Well firstly, I need to start read up more, I enjoy reading tech blogs (so far I follow some CF-centric blogs) and I enjoy finding out the best practices in software engineering field.
I want to push my fellow workers to their technical limit, read some more, play around with frameworks, do comparison studies on competitors, read some more and share your knowledge with the team. But maybe I am just being naive here, do people have the necessary skills and willingness to learn?
If we are advancing our development process and practices, we will leave some people behind. Brian has similar thought:
“This creates a problem. As our development group has kept advancing, we’ve embraced frameworks and design patterns and best-practices… So bringing someone in who isn’t at least somewhat familiar with these ideas is going to require a substantial ramp-up period to become productive.”
If I am advocating new things and everyone else is not on board with me (or just find it too hard to follow), this will just put more workload to me. I think I have already being overloaded with work compared to most of my colleagues (there is only one developer at the office who has more work than me I think -> but he’s top developer in the company, so it’s to be expected 
).
