Today I'm full of questions. Software development and programming is hard. Is a close encounter with layers and layers of complexity. Once we master one level, we open a whole new level. To tackle it one must employ multiple techniques. But they always involve trade-offs. How to balance programming using standard and maybe cumbersome idioms vs more elegant but more obscure idioms? What if the programming style is too personal and strange to others? Shall we settle for the lowest common denominator ? How do we balance the conflict between something harder to understand at first but easier to extend and maintain against something more familiar but with exponential complexity growth after each change? How do we maintain the "conceptual integrity" (F. Brooks) through the life of the system? As the project complexity grows, the need for sophisticated techniques increases. (I'm coming to the conclusion that if a developer can't comprehend some level of complexity, shouldn't be allowed to participate in the project without close mentoring). Refactoring is necessary because entropy. Every code base starts to degrade and loose integrity as evolves. I wonder if there's a code entropy metric... At what point a refactoring is good enough? When do you stop? At least your architecture should be stable, or you didn't validate it. I guess complexity is in the eye of the beholder. I found that a system composed of smaller simple pieces with complex interactions is easier to evolve than bigger pieces with simple interactions because each piece is internally complex and the limited interactions means its harder to combinate them in new ways. Of course, gratuitous complexity should be avoided at all costs. Sometimes I look for a "zen" approach to coding. At the end, I always take a pragmatic approach and find a trade-off that balances the forces. Isn't coding about that? Each line you write is a choice you need to make... At some point we need to use "introspection" and "metaprogramming" but not the programming techniques: introspection on how we approach problem solving and programming and metaprogramming on what we can do to program better.
7 comments:
I think small bits are important because they limit scope creep. Scope creep is really the most pernicious problem, and it happens on both sides--developer and customer. Both learn new things as the project progresses and it's hard not to incorporate the learnings.
A trivial but fun example: http://www.mysoftwarefilm.com/ This started out as a movie theme-based landing page for Intel's Software Partner Program and morphed into this. Yikes.
You're right, small bits help a lot (they can be managed more accurately too). And yes, scope creep is probably is caused by the difficulty of exactly defining the problem to be solved and again, "No silver bullet" says that's one of the essential complexities of software development... there's no easy way out. Iterative/incremental process help to improve the solution stepwise, getting closer to the "target"on each cycle...
Every code base starts to degrade and loose integrity as evolves.
Simply not true. Some projects start with ill defined goals. As the goals become clear, often the interfaces are restructured to reflect reality. They gain integrity as they evolve. I've worked on several that behaved this way.
Sometimes, you have to give up on backward compatibility to make this happen. It's certainly OK when you have 100% of the dependent code at hand.
You'd think that once you release something in the wild, your hands would be tied. However, several open source projects have been very aggressive at making changes to the interfaces, often justified by just these issues.
Ritchie wanted to change the operator precedence in C after adding the shortcut operators (&&...). But, programs had been written on three systems, and he didn't want to break them. Had he made the change (which in retrospect would have been manageable) then this too would have been a change increasing integrity.
@Stephen
Ok, "every" is too strong, but code is information, and is subject to entropy: you need to spend energy to reduce it. That normally means refactoring of the code or some alternative like that. I've worked on codebases that improved over the time too, but that is not something you get for granted or cheap. 99% of the time, is less effort to change the code than change the code AND maintain integrity (and a significant amount less than change the code and increase integrity). Of course, is better (and I would strongly recommend it) but it doesn't come for free, and that was somehow what I intended to say :)
(for sure, I didn't want to express any certainty in my post ;) )
I have been pondering a lot of these questions myself, but more at a systems level. My approach to the problem has been "Why is software development so different than other time-proven technical tasks?"
Through several accidental job assignments I have learned a lot about how to control the process through Configuration and Change Management, which helps reduce scope creep and code drift dramatically. The problem with it is that is must be fully embraced at the start of a project to have the desired effect, and most projects just starting up are not thinking about such things.
M@
British Dissertation Consultants offering best dissertation writing services for over a decade, ensuring to deliver the best quality dissertation drafts.
Post a Comment