|
Posts: 409 / Nickname: bv / Registered: January 17, 2002 4:28 PM
Don't Live with Broken Windows
March 2, 2003 8:05 PM
|
|
Artima.com has published part I of an interview with Pragmatic Programmers Andy Hunt and Dave Thomas, in which they discuss software craftsmanship and the importance of showing that your care about small problems in your code.---xj40dkcfea73---Artima.com has published part I of an interview with Pragmatic Programmers Andy Hunt and Dave Thomas, in which they discuss software craftsmanship and the importance of showing that your care about small problems in your code.
http://www.artima.com/intv/fixit.html Here's an excerpt: Dave Thomas: It comes down to showing that you care. Take for example some code that is kind of shared among the team, but primarily is mine. There's some code in there that is obviously bad, but it doesn't look like I care about it. I'm just leaving it bad. Anybody else coming into that module might say, "Well, Dave doesn't care about it. It's his module. Why should I care about it?" In fact, if you come into my module and do something else that's bad, you can say, "Well, Dave doesn't care. Why should I care?" That kind of decay happens to modules as well as apartment buildings. On the other hand, suppose I notice an edge condition that doesn't work in my code. I know it's a bug, but the bug is not critical to the application today and I don't have time to fix it. I could at least put a comment in there. Or, even better, I could put assertion in there, so that if the edge condition ever hits, something's going to happen that shows I'm on top of it. By doing that, first of all I make it easier to identify the problem. But I also show other people that I care about that enough that they will fix problems too when they encounter them. Andy Hunt: If you walk into a project that's in shambles -- with bugs all over, a build that doesn't quite work -- you're not going to have incentive to do your best work. But, if you go onto a project where everything is pristine, do you want to be the first one to make a bug? What do you think of Dave and Andy's comments? |
|
Posts: 2 / Nickname: davidcyp / Registered: January 28, 2003 8:58 PM
How about living with broken dreams?
March 4, 2003 2:02 AM
|
|
Do you guys (and girls) think it is possible to create clean and good code when you are demotivated and don't like your current project? When you drag yourself each day to the office, and when you're not proud on your job? Which solutions do you propose to solve the problem? I ended up on a project, for about ten months now, where a medium team developed allready for about 2 years. There wasn't much like a knowledge transfer, the only existing documentation was incredibely out-of-date, the environment wasn't stimulating for working, and I was dropped right into it. Coding a simple scrollbar on an existing screen can take up to 3 or 4 hours, just because somebody just refactored the underlying framework, which caused an error that is not detectable during refactoring, our because our own 'table' implementation is 'so well' (cynic) documented that the layoutmanager throws runtime exceptions when you apply normal coding practices to it. There are always heaps of problems when you just try to code something very basic. It's a very demotivating environment and I start to get the symptoms of a burnout. I really want to be a good programmer, but hey, I hate my job. What can i do? What should i do?
|
|
Posts: 1 / Nickname: rohit / Registered: May 1, 2002 7:02 PM
Re: How about living with broken dreams?
March 4, 2003 2:48 AM
|
|
Posts: 2 / Nickname: davidcyp / Registered: January 28, 2003 8:58 PM
Re: How about living with broken dreams?
March 4, 2003 3:09 AM
|
|
Indeed, it's all about money, it's all about business. But.. it's just that this project isn't running well since 2 years. They drop me, and expect that I fix all the code on my track, that isn't functioning. But, while I'm changing the code, somebody else is changing the underlying framework, so code that did work suddenly doesn't work anymore! This happens and happens again, and costed us allready weeks. But.. there's a deadline, and we can't make this deadline, because of these problems. So I get blamed for not getting the deadline. So I notice management, but they don't do anything about it. Off course I want to write state-of-the-art software, but I know that that is not always possible in real life. But I want at least write code which is acceptable, concidering time estimates and resources. But even this is impossible because of all other development problems that arise, and that shouldn't. But at the end of the day, the testers and users complain to me, not to those who changed something lower-level which causes my or my teams'software not to work. This situation has frustrated me so much that I tend to lose the faith in my own capacities. And it led to daily headaches, fysical complaints, etc. So I know, I should change my job, but given the economical situation, that is not an easy thing to do. Certainly not because I work for a company with much name and fame in the java world.
|
|
Posts: 1 / Nickname: chrishughm / Registered: March 3, 2003 10:22 PM
Re: How about living with broken dreams?
March 4, 2003 3:42 AM
|
|
It's a tough situation, and it takes time to deal with it.
It's hard to find another job, but even if your current employer doesn't deserve your best work, YOU do. The habit of doing the best work you can is hard to regain if you let it slip ... the broken windows of the soul matter too. What is good work in your current situation? It doesn't sound like coding alone is sufficient to deal with the problems. To address this sort of situation, you need first to win respect, and that takes time. I'm hesitant to make specific suggestions from outside, but maybe it would be useful to make a test suite to alert you when the framework has changed. This would 1) save your time debugging 2) enable you to make rapid fault reports to whoever is breaking it 3) show an example of a better development technique In my own experience, development tools are a great place to concentrate in this sort of situation. Others are mostly so focussed on procduction that they neglect productivity, like someone who's got no time to sharpen his saw, because he's got too much wood to cut. Well designed tools eventually become central to the team's method of working, which makes you visible to management. To get the tools right, you've got to listen to everyone, so you can show both coding skills and respect for others. Incidentally, you are in a great situation to study project management, since you've got a living example of what not to do. If over time your efforts aren't appreciated, at least you've enhanced your skill set and your character, and eventually you'll find an employer who deserves you. |
|
Posts: 4 / Nickname: pragdave / Registered: March 4, 2003 6:00 AM
Re: How about living with broken dreams?
March 4, 2003 11:57 AM
|
|
> Do you guys (and girls) think it is possible to create
> clean and good code when you are demotivated and don't > like your current project? This is an excellent point. There are many challenges facing developers, and not all of them are technical. One of the big messages we push when we talk to managers is that they need to start treating developers less like plug-compatible resources and more like individual people. As such, they should expect to have people how provide a lot more value than others. Why do they not then pay these people appropriately? Managers also need to be better at handling the dynamics of teams. This is particularly hard when dealing with developers; perhaps we should learn from industries with similar kinds of issues (advertising agencies, perhaps). However, fixing broken windows is still an important practice. If you live in squallor, no amount of happy talking from on high is going to make it better. Fix what you can fix, and set an example for the rest of the organization, challenging them to do the same. |
|
Posts: 5 / Nickname: yow / Registered: February 18, 2003 11:44 AM
Re: Don't Live with Broken Windows
March 3, 2003 7:22 PM
|
|
Interesting and provocative article!
I think this approach only works when you have a fixed design - such as a cathedral. In such a case, any broken code you fix will be fixed forever... But if you are doing something truly new, the design will change and change again, as the process of writing the program is a process of discovery and exploration of what the problem really is, rather than solving it. So, why spend all that time perfecting your code, when it will be thrown out anyway? Of course, if you do notice that the code is broken, it's better to retain the value of that insight rather than waste it - if you can add a brief comment or assertion in a few seconds, then you have preserved your insight, so it can be followed up on later. But to actually *fix* all those broken windows takes a lot of time... usually, projects are over-ambitious, and there are so many things to do that there just isn't time. And worse, the true complexity of a project is often uncovered only once you are deeply in it... The "iterative prototyping" approach is the opposite of fixing all the broken windows. It implies "don't fix it until you are sure you need it". The broken window approach is a good one for projects with static designs - that is, when the designers actually understand the project (and not just think they do). Brendan Macmillan PS: There is some controversy about whether the "broken windows" theory actually explains the decrease of crime in New York, since crime rates dropped all over the US during the same period. But it certainly seems very plausible! And anecdotally, I've heard it said that machines in a factory that are freshly painted need few repairs (the paint is not needed, but they get looked after better, because they *look* cleaner - like a new Jaguar). |
|
Posts: 4 / Nickname: pragdave / Registered: March 4, 2003 6:00 AM
Re: Don't Live with Broken Windows
March 4, 2003 11:51 AM
|
|
A couple of interesting points raised here.
Firstly, Andy and I both practice extremely iterative development. We find that fixing stuff as we go along is actually an enabler for this. The alternative is to build up a bunch of technical debt which eventually becomes overwhelming. We also find that small problems left unfixed tend to produce subtle bugs later, bugs that can take disproportionately long to fix. So I'd argue pretty strongly that keeping your code clean is as (if not more) important when you're developing iteratively. The second point is implicit in the first answer: I don't think there are many static designs :) |
|
Posts: 10 / Nickname: tpv / Registered: December 9, 2002 1:41 PM
Re: Don't Live with Broken Windows
March 4, 2003 9:42 PM
|
|
> The "iterative prototyping" approach is the opposite of
> fixing all the broken windows. It implies "don't fix it > until you are sure you need it". Does it? I think it says "Don't put the windows in until they're needed". But once you've decided that they're needed, you better keep them functioning. You can think of painting the interior of a house as a possibly better metaphor in this case (or maybe not). It's OK to build the house, and not paint the walls. You don't need the paint yet, you're still in the process of building it. But once you start painting, you at least need to finish the room you start. People are comfortable walking into a room that hasn't been painted yet - they know it's not finished, and if the walls are in place, and are solid and in good shape, then they'll happily believe that the building is going according to plan. But if you paint half a wall, and then they walk through it (the house, not the wall :)), then it looks messy. It looks half-done. It looks like the plan isn't working. Especially if the wall is still half-painted when they come through a week later.Much better never to paint, than to paint half a wall. If you don't need windows, then don't build them. But if you decided that you needed them, then why are you leaving them broken? And if you don't think you need them anymore, then pull them out. Having code that isn't needed has a cost. Every line of code has a cost to maintain, and a cost to read. If you have lines of code that do nothing, then get rid of them. And if you're happy for your window to lie around broken, then you obviously don't need it, so pull it out. At least then it will look like a conscious decision to not have windows, as opposed to laziness. |
|
Posts: 5 / Nickname: yow / Registered: February 18, 2003 11:44 AM
Re: Don't Live with Broken Windows
March 5, 2003 8:26 PM
|
|
Good points - I think our different points of view are to do with there not always being a clear distinction between the "lack of a window" and a "broken one".
For example, an unpainted room is an incomplete and therefore is a "broken window" in that sense. It depends on your perspective, which is to do with what the purpose of the room is. But when it *is* clear that there is a window there, and it is broken, I agree very much with your point to not leave it broken. Perhaps the relevant distinction is simply whether it *looks* or *feels* half-complete (ie broken) to someone, not whether it "really" is or not, since the issue is largely psychological. Eg. psuedo-code that is half-way converted to working code is broken, even though it won't compile. > If you don't need windows, then don't build them. > But if you decided that you needed them, then why are you leaving them broken? > And if you don't think you need them anymore, then pull them out. Again, an issue is choosing the unit of a "window" in software. But if you have chosen a unit, what if it takes more than one day to complete it? Ie what if you can't paint the whole room in one go? It seems the concept of a broken window leads to the concept of choosing units that you *can* complete within one sitting... and how it important it is that this looks and feels like a unit. I personally find chosing doable units that are definite units and that also give you a sense of progress towards the greater goal can be very very tricky indeed! But I do it all the time, because I think it's extremely important to get closure - and one of the things I like about agile methodologies. PS: of course, I may be stretching the meaning of the word "broken" in the above, and when one sees something as "broken" which is really only "incomplete or unfinished", perhaps one is being unnecessarily and counterproductively perfectionistic? ;-) |